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

[Donald Eastlake <[e-mail]>]

Hi Thomas,

On Wed, Mar 20, 2013 at 5:19 PM, Thomas Narten <[e-mail]> 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.

The use of "mode" and "enable" all imply to be a big toggle-switch.
There is no such big toggle-switch.

It many cases, it might be a bit obscure to tell if a TRILL switch is
FGL-safe or VL if there are no FGL-edges/FGL-packets to tickle it into
FGL behavior. But an FGL-safe TRILL switch always behaves as an
FGL-safe TRILL switch. In particular, it always announces itself in
its LSP as FGL-safe and it always conforms to Section 4.5 of the draft
as far as distribution tree construction goes. So, even in the absence
of any FGL-edge TRILL switches and any FGL packets, an FGL-safe TRILL
switch behaves in a way that is still distinguishable from the
behavior of a VL TRILL switch.

>> 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 [FGL-edges] can be introduced.

While this is the smoothest and most complete migration scenario,
there certainly might be TRILL switches that cannot be upgraded to be
FGL-safe or FGL-edges might appear before step 3 is complete due to
misconfiguration or whatever. In either case, you still must safely
handle FGL packets.

> 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?)

Almost. See above for the ways (admittedly a bit obscure) that
FGL-safe TRILL switches would be behaving differently from VL TRILL
switches even when there are no FGL-edges/packets.

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

No. Co-existence of FGL-safe and VL TRILL switches in one campus is
the whole point of mandating the behavior in Section 5.1. So you will
be safe and can handle FGL packets within a contiguous island of
FGL-safe TRILL switches regardless of the presence of VL TRILL
switches.

Furthermore, if the nature of your FGL-safe TRILL switches that are
directly adjacent to a VL TRILL switch is such that you can use step
(A) in Section 5.1, you can even communicate VL packets between end
stations attached to VL TRILL switches and end stations attached FGL
TRILL switches in your campus. (But this will not be possible if your
FGL-safe TRILL switches that are immediately adjacent to VL switches
cannot support step (A) and have to use step (B).)

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> What is it that I'm not understanding?
>
> Thomas