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

Radia Perlman <> Wed, 20 March 2013 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 310CA21F8A8F for <>; Wed, 20 Mar 2013 14:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QJJ-JL8T6lOw for <>; Wed, 20 Mar 2013 14:44:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::232]) by (Postfix) with ESMTP id D310F21F8A18 for <>; Wed, 20 Mar 2013 14:44:02 -0700 (PDT)
Received: by with SMTP id ec20so3823780lab.23 for <>; Wed, 20 Mar 2013 14:44:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XqO7wdA3ymkL566c1Nn0+36NmFS2e/w4i/PTvnL0Xzo=; b=MHqzVyiHGEIWnsNDvCQMxaLcxAM/0sRRS426/kXiIMu0TuwZ0gmZrgRGxTaI+3rnUF 9NW/HADy2RMtLGULUSjbO1xHeMSxBN7aFkxH8ZgolvZWDEreNzSl3x373LxRP5dF2yAo t0QzxqohM1rnxAUVqVizkY46uExui2jQfYdBR4chxMgeAUVNoOEo+JQhz2MCnFL79E7q 2XdmIkGa3P0VUdkRob14x1FWStq2+AeBK0zAc6NJuuA5zMTigZ65VG1i3g28bp+AZlF5 h4F3OITGCcareV2HF9pCjhNLaZPgJfu9v7u3dSjFC8DN6A7WB69DfqxSHqpTnrlKo0fT K3hw==
MIME-Version: 1.0
X-Received: by with SMTP id d7mr10371475lbb.8.1363815841674; Wed, 20 Mar 2013 14:44:01 -0700 (PDT)
Received: by with HTTP; Wed, 20 Mar 2013 14:44:01 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 20 Mar 2013 14:44:01 -0700
Message-ID: <>
From: Radia Perlman <>
To: Thomas Narten <>
Content-Type: multipart/alternative; boundary=e0cb4efe29d2c83fae04d8621e30
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 21:44:04 -0000

I think we are having a violent agreement.

And just for a bit of history...the current design's view of mixing VL
transit RBridges into a campus that has FGL frames wandering around is that
it is a misconfiguration.  The 4 steps that you quoted:

> 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.

is intended to be the way that migration is done.

There was a previous design proposed at some point that was a bit more
ambitious about mixed nets (VL transit RBridges and FGL frames), that had
FGL RBridges compute different forwarding tables to edge guys that claimed
to be connected to FGL links...where those paths avoided any VL transit
RBridges.  One person objected that that was needlessly ambitious...that
there was no reason to have long-term mixing of VL transit RBridges while
there are FGL frames.

So we came up with the less ambitious rules of "FGL-safe", and people
seemed to agree that it wouldn't be that big a deal to make everything
FGL-safe, so that's why the design is the way it is.  It's
need to compute forwarding tables differently for FGL-edge guys.

But it's a bit less interoperable than the previous design because if you
do accidentally have a VL guy in the middle, the network might become
partitioned with respect to FGL frames, whereas with the other design, the
FGL frames would get routed around the VL guy in the middle.

I think if it's really easy to upgrade all the existing RBridges to
FGL-safe, then this is a fine design.


On Wed, Mar 20, 2013 at 2:19 PM, Thomas Narten <> wrote:

> Radia,
> > 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 FGL-safe,
> > 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
> model:
> > 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?
> Thomas