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

[Sanjay Sane (sanjays)]

I read the draft to understand the specification of F-tag, and here's
what it reads 

===========
The Forwarding Tag (FTag) identifies the forwarding topology assigned to
a given frame. In current enterprise networks, for a given frame it is
possible to pick from multiple topologies on which the frame can be
forwarded. 
<snip>
===========

If there's a choice of multiple topologies to forward the packet on, and
if that choice is to be made by the source-rbridge, and if subsequent
rbridges should forward the packet along that chosen topology, THEN

rest of the rbridges would need something (during the forwarding
decision) to idenfity what choice was made at the source-rbridge. 

Is that (or isnt that) one of the purpose of having FTAG ?

-Sanjay

 

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Friday, October 13, 2006 12: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