Re: [trill] FGL "safe" mode in fine labels

Donald Eastlake <> Wed, 20 March 2013 22:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CFC721F8D45 for <>; Wed, 20 Mar 2013 15:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.1
X-Spam-Status: No, score=-102.1 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_11=1, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qk1j86nrTj8D for <>; Wed, 20 Mar 2013 15:23:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::236]) by (Postfix) with ESMTP id A926C21F8D3A for <>; Wed, 20 Mar 2013 15:23:15 -0700 (PDT)
Received: by with SMTP id va7so2192518obc.41 for <>; Wed, 20 Mar 2013 15:23:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=vd9GgtX6lOp4B2d8iLST1Fz4x0AD/6mb0Kh7uLAtEzc=; b=zXOwnQFf3wWZ1VtF6pD0GwHzmzoDuO6P/lYPt0+p1L/7Ld5TMh9pPdxJ+0nj8gIvIP XeW4ReILN+rLR7+hIL0uu1i4VC9JsC3DEH90aajvtWFoi4tQNB/zCeVNkgXdrfp+7NAO nGRrtv5A5rAmL2YcH2BxPusm+lEeqBotO7YVgnWIEfnClSayIklltpA2II2bCTuS2iZi Nb6cW6HjqVMHc0EE8Swo0QujTLVN8RC1jgjuNZ6gWN960roHFPIidU0ZBA6GW2wYkEHZ Dm5okdIk0L5ESDnUhaOu538m33Yx20rUfZsvy6uL43EYKlavka4HlZOUU3p8MqTcDxBU QzHw==
X-Received: by with SMTP id lx17mr5282463obb.63.1363818195277; Wed, 20 Mar 2013 15:23:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 20 Mar 2013 15:22:55 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Wed, 20 Mar 2013 18:22:55 -0400
Message-ID: <>
To: "Matt Anger (manger)" <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Thomas Narten <>, Radia Perlman <>, "" <>
Subject: Re: [trill] FGL "safe" mode in fine labels
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Mar 2013 22:23:16 -0000

Hi Matt,

On Wed, Mar 20, 2013 at 5:34 PM, Matt Anger (manger) <> wrote:
> That is not what the spec as I interpret it says.
> In 2) you can have FGL frames, but they are only allowed to be sent across
> switches that are FGL-safe.
> Meaning if you don't have a complete route A<->B where all the in-between
> switches are FGL-safe, then the frame can NOT be transmitted as FGL.

Well, that numbered series is supposed to be a time sequence for
smooth, total, VL to FGL migration assuming that all your VL TRILL
switches are upgradable to FGL-safe.

>    S1----S3
>   /  \  /  \
> A<    ><    >B
>   \  /  \  /
>    S2----S4

You are certainly correct that you can't safely send an FGL packet
between A and B unless there is path between them in your campus that
only goes through FGL-safe TRILL switches.

> In this example you need one of (S1 and S2) and one of (S3 and S4) to be
> FGL-safe for FGL frames to be able to go from A<->B


> So if S1 and S3 are FGL-safe and S2 and S4 are NOT FGL-safe, then the link
> costs *must* be calculated such that FGL frames always go A->S1->S3->B
> (and never over S2 and S4 which are NOT FGL-safe) and FGL is ok to be
> enabled.

If FGL packets are going between A and B, they must both have
announced interest in one or more fine grained labels such that they
both have a label in common. Lets take your assumptions and assuming
there are point-to-point links between S1 and S4 and between S2 and S3
(as opposed to a four port multi-access link). Then A, S1, S3, and B
will all see a VL TRILL switch out one or more ports. Then one of the
two paragraphs immediately below will apply:

If those four TRILL switches have the capability of configuring their
ports facing VL TRILL switches to discard FGL frames, then they can
use step (A) in Section 5.1, so the links between them and the S2 and
S4 VL TRILL switches will be usable but with very high cost. This has
the advantage that, for example, an end station attached to S2 or S4
could communicate with an end station attached to one of the FGL-safe
TRILL switches, although, of course, that communication would be
limited to VL packets. This provides improved interoperability even
for VL TRILL switches that cannot be upgraded to FGL-safe.

On the other hand, if those four TRILL switches cannot be configured
to discard FGL frames on their ports facing VL TRILL switches, then
then they must use step (B) in Section 5.1 which will sever data
connectivity over the links between any of S2 and S4 and any of A, S1,
S3, or B. This is unfortunate but it is the only safe thing to do
under the circumstances.

Perhaps the inclusion of something like this example in an appendix to
the draft would help.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> -Matt
> On 3/20/13 4:19 PM, "Thomas Narten" <> wrote:
>>> No!  There isn't any mention in the document of "operating in VL
>>> mode", whatever it is you might mean by that.
>>Operating in "VL mode" (to me) means you don't know anything about FGL
>>and operate as described in RFC 6325 et al. I.e., the base mode of
>>operation for TRILL. I think it's useful to define a term like "VL
>>mode" to describe that behavior to distinguish it from RBs that have
>>somehow enabled and are using FGL.
>>> If R1 is FGL-safe, and if R1's neighbor R2 does not claim to be
>>> then R1 does not forward FGL frames to R2.  R1 does not do anything
>>> different if some non-neighbor of R1, say R3, is not FGL-safe.
>>The above says to me that you now have a TRILL campus where R1 does
>>process FGL frames and R2 does not. But doesn't that contradict the
>>> 1) VL-only (today's deployment), then
>>> 2) A mixture of VL and FGL-safe, until
>>> 3) EVERYone upgraded to FGL-safe, then
>>> 4) FGL-links can be introduced.
>>Or maybe we are having a violent agreement? if we are at step 2)
>>above, then isn't the entire campus operating in "VL mode"? I.e., at
>>step 2, no one is sending/receiving/processing FGL frames. (Right?)
>>It's not until step 3/4 that you see *any* FGL frames being used. And
>>for that, you can't have *any* RBs still operating only in VL mode -
>>they *all* have to support FGL.
>>What is it that I'm not understanding?
>>trill mailing list
> _______________________________________________
> trill mailing list