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

[Anoop Ghanwani]

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

On Thu, Jul 28, 2011 at 8:05 AM, Radia Perlman <radiaperlman at gmail.com>wrote:

> 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 <linda.dunbar at huawei.com>
> 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
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110728/fc8ebc82/attachment.html