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

[Gray, Eric]

Radia,

	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.

	:-)

--
Eric

--> -----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
--> 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
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->