[rbridge] Offlist Re: Critical bits for options

[Radia Perlman]

John -- I'm answering your question about "customer ID" offlist because 
it's kind of orthogonal to this thread,
which is how to encode the options. I think it was discussed on the list 
awhile ago, and I will want to
discuss it on the list at length at some point, but I don't want to 
distract people now.

So...what was I mumbling about with "customer ID"...

Suppose you have a provider that is gluing together customer Ethernets. 
Each customer is using VLANs, and with
overlapping numbers. VLAN "3" for one customer is not the same as VLAN 3 
at another customer, and your customers
would not want their VLAN 3 traffic sent to the other customer's VLAN 3.

The way I'd like to do this is for there to be kind of "level 1 TRILL" 
and "level 2 TRILL". Within a customer campus, the
VLAN would be the 12 bit thing defined by IEEE 802.1Q. However, an edge 
RBridge, RB1, at the provider (ones that connect to
customer campuses but are participating in the backbone that connects all
the customer campuses) know that there is actually another level of 
hierarchy; "customer ID". The customer ID can take any
form -- it need not look like a VLAN tag. For instance, it could be a 5 
byte number, or it even could
be variable length. I'll use ASCII strings in this email for the 
customer ID.

RB1 (edge provider RBridge) is configured to know that this port goes to 
customer "ACME-CORP", and this other port goes
to "VWX-ENTERPRISES". To edge RBridges, the concatenation of "customer 
ID" and "VLAN" acts as a larger VLAN space. Let's
call that space "C-VLAN", for "concatenated customer ID and VLAN".
So RB1 keeps a learning table for C-VLANs, and otherwise performs just 
like an ingress/egress RBridge in the current TRILL spec.
When RB1 sees a native frame on a port that RB1 is configured to assume 
belongs in
("ACME-CORP", VLAN 3), it looks in its learning table for C-VLAN 
("ACME-CORP", VLAN 3)
to see if it knows which egress RBridge owns the destination. If RB1 has 
learned that the frame should be forwarded across the
backbone to RB2, then RB1 encapsulates towards RB2, but adds the 
critical ItE option "customer ID="ACME-CORP".

Transit RBridges don't care about the customer ID. Only the egress, RB2, 
needs to understand it. If RB2 does not understand it, then
there is the danger RB2 will forward it to a different customer's "VLAN 3".

Now one could argue that RB1 would not send it to RB2 if RB2 didn't 
understand the "customer ID" option, and I have to admit
I am not all that enthralled with "critical" options.

Hope that clarifies somewhat.

Radia






Drake, John E wrote:
> Radia,
>
> The customer ID listed in your e-mail, below, makes no sense to me.  How
> would the ingress discover this information and what would the egress do
> with it?