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

[Dinesh G Dutt]

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

Dinesh
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
> 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
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan