Subject: Re: [rbridge] suggestion to "draft-eastlake-trill-rbridge-fine-labeling-01"

From: Radia Perlman <[email-masked]>
Date: Thu, 28 Jul 2011 08:05:14 -0700

I don't understand, but let me write out the alternatives I think
there are, to see if perhaps I do understand.

a) in some cases there is no virtual switch (no hypervisor), and the
packet will come from an endnode with no VLAN label.  In this case, if
it is a DT VLAN (one that requires two tags), then the RBridge will
insert two VLAN tags.

b) if there is a vswitch that has added one VLAN, then the RBridge
would (presumably) be configured to map (input port, VLAN tag) to DT
VLAN, and logically strip the existing VLAN tag and replace it with a
fine-grained label (two VLAN tags).  In which case, I don't understand
why it would matter whether it is C or S.  At the egress, the opposite
would have to happen.  The RBridge would have to map from the
fine-grained label to the label the vswitch will want to see.

I don't have any strong opinions on this (probably not even weak
ones), especially on whether it's a C or S tag.  But I would like to
understand the practical implications of the four possibilities (CC,
CS, SC, SS).

Radia

On Thu, Jul 28, 2011 at 7:46 AM, Linda Dunbar <[email-masked]> wrote:
> The draft describes edge RBridge adding two VLANs.
>
> But most likely the native Ethernet frames coming to edge RBridge is already
> VLAN tagged because Virtual Switches within a server or Blade switches on
> Server usually  add the VLAN to differentiate the traffic.
>
>
>
> Therefore, if TRILL needs to have another layer of tag for more finer
> traffic segregation,  a more practical approach would be edge RBridge adding
> another tag on top of the VLAN which is already on the data frames.
>
>
>
> There are multiple options for this new tag added by edge RBridge. The draft
> should at least describe those options and list pros/cons of each option. If
> the conclusion is that the new tag added by edge RBridge has to be VLAN,
> then it needs to give a different EtherType for the outer VLAN added by edge
> RBridge (which can (or should) be different from the EtherType assigned to
> S-tag defined by IEEE802.1ad)
>
>
>
> Once the new tag is added by edge RBridge, VLAN carried by the native
> Ethernet frames can become locally significant. That is how TRILL can reach
> more finer traffic segregation. There should be a section in the document
> describing this.
>
>
>
> Linda Dunbar
>
>
>
>
>
>

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Jon Hudson <[email-masked]>
Date: Thu, 28 Jul 2011 14:01:29 -0400

On the hypervisor side:

If they are using 1g nics, then VLAN tags are not often used. They will just use one link per VLAN.

If they are using 10Gb links (a small but growing number) then you could easy see many many tags as you will have 20-30 VMs sharing 2 10Gb links 

Side note: I have one poor customer with 23 1Gb links coming out of each sever. Then add 2 FC ports and console and it 26 physical cable per hypervisor =)

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 28 Jul 2011 13:23:06 -0700

The main issue I see with this is the ability for ST devices to figure
out whether or not the frame is DT.  If we use the CC option, an ST
device has no way to figure out it has received a DT frame.  It will
process it just as it would an ST frame.  I am sure folks will ask the
question "well show us how that would happen?".  The point is,
if there is a way to protect against this, then why not do that?

So I am very strongly in favor of the top tag being an S-tag and
the bottom one being a C-tag.

I don't think it's worth discussing SS and CS (first one being
the top tag).

Anoop