[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Eric.Gray at marconi.com
Fri Oct 13 12:42:24 PDT 2006
I've noticed the same with mine. This results in serious
problems with posts that "cross in the mail."
I believe it may be because the mailing list server - not
being accustomed to seeing a single posting in a period of less
than a month - has been overcome by the recent posting volume.
--> -----Original Message-----
--> From: rbridge-bounces at postel.org
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Friday, October 13, 2006 3:21 PM
--> To: Caitlin Bestler
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Range of appllicability (was Re: TTL
--> only - was RE: New fields in shim header?)
--> 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
--> 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
More information about the rbridge