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

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Mar 2013 14:59:18 -0400

I spent some time rereading the current fine labels draft
(draft-ietf-trill-fine-labeling-05.txt) and the January email thread
on "safe mode" (Re: [trill] Explaining three options for upgrading to
FGL (fine-grained-labeling)).

But I'm still not sure I understand...

What exactly is "FGL-safe mode"? I see the definition in the document,
but it doesn't explain at a high level what this mode is intended to
do. I.e., what the principles are. I.e., what does it mean for a TRILL
campus (as opposed to an individual RB)?

Is "safe" mode just another word for "FGL capable", i.e., the
implementation is capable of fully supporting FGL?

Or is there a broader definition for "capable"? (Some other messages
seem to suggest this) If so, what is the difference?

Finally, what is the migration path from VL to FGL in a real
network?

Back in January, Radia said
(http://www.ietf.org/mail-archive/web/trill/current/msg05632.html):

> So...again...the migration phases in option 2 are
> 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.

>From the above, I conclude that there is no FGL traffic and no actual
usage of FGL capabilities until step 4.  That makes sense to me, but
this is not explained clearly in the current draft. Indeed, it's
pretty easy to conclude from the draft that an RB operates in both FGL
and VL mode at the same time from the way the behavior is described
(often talking about an RB having some links doing FGL and some doing
VL).

PS, to me "FGL safe" doesn't seem like the right term. Wouldn't "FGL
capable" be more accurate, and then distinguish between an
implementation fully supporting FGL (i.e., is "capable") vs. that
capability being enabled operationally? That would seem to more
clearly reflect what (I think) is the intended behavior.

Thomas

---

From: Radia Perlman <[email-masked]>
Date: Wed, 20 Mar 2013 13:08:49 -0700

I never get too excited about what words are used, but the terminology
"FGL-safe" is intended to mean "doesn't do anything bad with FGL traffic"
as opposed to being able to understand FGL labels.
So, indeed, "FGL-capable" would, I believe, evoke a different image from
"FGL-safe", since the reader would assume from the word "FGL-capable", that
it would actually be able to parse FGL labels.  And indeed, it doesn't
matter to R1 whether distant RBridge R2 is FGL-capable...the only time R1
needs to do something different is if R2 is not FGL-safe.

Whether R2 is indeed "FGL-capable" is really only a local matter...whether
it can sink or source FGL traffic, so obviously if it isn't FGL-capable, it
won't actually claim to be connected to an FGL link.

I thought the writeup that I'd done explaining the four steps, that you

> 4) FGL-links can be introduced.

was clearer than what is in the current draft, but I didn't argue since I
believe the current draft does have that technical behavior.  Most drafts
could be written more clearly, but we really are way overdue for issuing
this, and I wouldn't want to delay it because of editorial issues with the
draft.

Radia

On Wed, Mar 20, 2013 at 11:59 AM, Thomas Narten <[email-masked]> wrote:

> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Mar 2013 16:32:24 -0400

Hi Radia.

> "FGL-safe" is intended to mean "doesn't do anything bad with FGL

I understand that, but what is the value in writing a standard with
that sort of description? The FGL document should be about what you
have to do to be compliant and how to get interoperabilty. "Not doing
anything bad" doesn't seem like the right way to say that...

> as opposed to being able to understand FGL labels.

Could someone then please layout what capabilities an "FGL safe" RB
has that a "fully compliant" RB does not? What is the difference?
Better yet, point me to text in the document that explains that.

> needs to do something different is if R2 is not FGL-safe.

Actually, all they need to know is whether there is *one* RB that
*doesn't* understand FGL. If one such RB exists, everyone just
operates in VL mode. (Right?)

If that is what the intended behavior is, why can't the document just
come out and clearly say that? 

> won't actually claim to be connected to an FGL link.

I find this sort of definition somewhat maddening.

What we need to clearly describe is when an RB is capable of
supporting FGL (fully) and when can FGL be enabled on a TRILL campus
(and then on which RBs).  And will this be clearly understood by an
operator trying to actually use and deploy the functionality?

> this, and I wouldn't want to delay it because of editorial issues with the

Great. But it's really frustrating when folk start saying "I agree the
document isn't so good, but we need to publish it anyway" with the
implication being "no thanks for taking the time to review and trying
to make the document better".

Thomas

---

From: Radia Perlman <[email-masked]>
Date: Wed, 20 Mar 2013 14:03:39 -0700

The document does formally define , right in the introduction, and quite
clearly I believe, what "FGL-safe" means.  It does not mean that you must
be able to ingress or egress FGL frames.

And to repeat...the difference between FGL-safe and "fully understanding
FGL" is that it is fine to be a transit RBridge with FGL-labeled frames
even though you don't parse the FGL label, and can't ingress-egress them.

>>operates in VL mode. (Right?)

No!  There isn't any mention in the document of "operating in VL mode",
whatever it is you might mean by that.

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.

And when I said that the document could be improved editorially, I was just
saying that pretty much any document could be improved editorially.  I
think the document is sufficiently clear.  It's written more from "this is
exactly how you behave as an RBridge" rather than tutorially, and it's
longer than probably necessary, and indeed it was rewritten from the more
tutorial style (that I'd written most of) because of someone complaining
that there was too much emphasis on explaining the transition.  With
editorial stuff, we'll never ship anything if we wait until everyone is
happy with the style, because everyone has different style preferences.
 The real question is whether it's accurate and sufficiently clear, which I
believe it is.  I believe it is clearer than most IETF RFCs.

Radia

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Mar 2013 17:19:21 -0400

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. 

> 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

> 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

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 20 Mar 2013 17:34:10 -0400

Hi Thomas,

> anything bad" doesn't seem like the right way to say that...

There is transit interoperability and there is ingress/egress
interoperability. FGL-safe is about transit interoperability. This is
important because if you have FGL-unsafe (i.e., VL) TRILL switches in
the campus, then you have to be careful that they never get FGL
packets. If all the switches are FGL-safe, then you don't have to
worry about that.

> Better yet, point me to text in the document that explains that.

An FGL-safe TRILL switch conforms to the list in the Introduction. I
believe the Introduction tries to be somewhat tutorial on FGL-safe and
migration.

The right comparison is FGL-safe with FGL-edge. An FGL-edge TRILL
switch has to be FGL-safe but also has port(s) configured to actually
ingress/egress FGL. So, it is the other way around from what you said.
A "fully compliant" (a term not used in the draft, perhaps what you
mean is "fully capable" but that term isn't used either) FGL TRILL
switch has to be FGL-safe and is also capable of being an FGL-edge.

> operates in VL mode. (Right?)

There isn't anything anywhere in the draft about any kind of FGL TRILL
switch ever just operating in VL mode. The required behavior to make a
mixed campus safe, as described in Section 5.1 (FGL and VL Mixed
Campus) is that FGL TRILL switches that observe an immediate neighbor
that is VL must take either step (A) or step (B) and, in addition, all
FGL TRILL switches must take step (C) whether or not there are any VL
TRILL switches in the campus.

> operator trying to actually use and deploy the functionality?

Well, an earlier version of the draft used "Limited FGL" and "Full
FGL" and there was substantial negative feedback and about that.

There isn't really such a thing an "enabling" FGL on a campus or TRILL
switch - although there is such a thing as configuring a TRILL switch
port to ingress/egress FGL - something you presumably can't do if that
capability isn't supported by the TRILL switch port you are trying to
configure. Seems to me it would be possible to have a TRILL switch on
which some ports were capable of FGL ingress/egress and some ports
were not.

If you have sources/sinks of FGL, i.e., FGL-edge TRILL switches,
before all the TRILL switches in the campus are FGL-safe, something
that could always happen, then you may either get sub-optimal routing
or you get data isolation between the FGL and VL TRILL switches,
depending on whether your FGL-safe switches support step (A) or step
(B) in Section 5.1.

> to make the document better".

If there are clarifying editorial changes I don't see why they can't be made.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Matt Anger (manger)" <[email-masked]>
Date: Wed, 20 Mar 2013 21:34:16 +0000

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.

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

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.

-Matt

---

From: Radia Perlman <[email-masked]>
Date: Wed, 20 Mar 2013 14:44:01 -0700

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

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

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 20 Mar 2013 17:59:49 -0400

Hi Thomas,

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

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

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

> 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

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 20 Mar 2013 18:22:55 -0400

Hi Matt,

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

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

> FGL-safe for FGL frames to be able to go from A<->B

Right.

> (and never over S2 and S4 which are NOT FGL-safe) and FGL is ok to be

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.

Thanks,
Donald

---

From: [email-masked]
Date: Wed, 20 Mar 2013 17:08:03 -0700

To be honest I had no problem understanding this draft. I am far from the
technical guru of switches as a few of you can testify. Yet, this draft
was very clear to me. I understood that a switch could do four possible
things with a FGL packet.
1. It understands it, does what the packet says, and passes it on
2. It doesn't understand it, but passes it on to another switch that does
3. It drops the packet because it doesn't understand it
4. It barfs

To me number one was an FGL capable switch. Number two was an FGL safe
switch.  Number three isn't useful and won't be considered safe in getting
the packet across the network. Number four was not safe under any
condition.

I wish to thank the writers for taking the time to include enough
information such that someone like me can read these specifications and
understand them. I know it takes a lot more of your time to do so and I
really appreciate it.
thanks again
gayle

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Mar 2013 21:03:20 -0400

So, it seems to me that there are several different deployment
combinations involving VL and FGL.

1) Mixture of VL only and FGL-safe RBs, but no FGL-edges. To me, this
case is pretty uninteresting, in the sense that since all the RB-edges
understand only VL, there is zero reason to use FGL anywhere. Thus, in
this case, I would expect FGL-safe RBs to advertise that they are
FGL-safe, but all RBs would operate in VL-only mode.

Does this make sense?

2) A second possibly uninteresting case consists of a mixture of VL
only and FGL-safe RBs, all edges are FGL-edges. In this case, you do
have VL-only transit RBs (they are not connected to edges). This case
is sort of weird in that the VL-only transit RBs are useless and
aren't used. So I'd just rule this case out of scope.

Well, except an operator needs to be aware of this restriction, so
they aren't surprised.

Does this make sense?

3) The interesting cases are where you have a mixture of VL-only and
FGL-safe RBs AND a mixture of VL-edges and FGL-edges. This is the
tricky case.

This leads to two different problems.

3a) First, if you are using both VL-Edges and FGL-edges, what is the
interoperabilty model intended to be? If RB1 is VL-only and supports
VLAN 1, but RB3 is an FGL-edge and also accepts traffic on VLAN 1,
what is supposed to happen? Is traffic supposed to be relayed between
those two VLANs? Why or why not?

My impression from the document is that the above case is handled by
saying "ships in the night", you don't get communication in that
case. Is that correct?  Either way, I think the document should
explain this more directly -- its critical to understanding the
transition approach when deploying FGL.

3b) Whatever the answer for 3a), there is a separate problem that you
may have FGL-safe RBs and VL-only RBs, and you can't forward FGL
traffic via a VL-only RB. That means that the SPF calculation that
creates the TRILL routing table conceptually runs two different
instances: one covering only FGL-safe RBs, another covering all
RBs. FGL frames are only sent using the routing table built from the
FGL-safe RBs, VL frames are sent via the other table. The edge RBs
Ethernet Frames ingress into the TRILL network decide which
encapsulation (VL or FGL) gets used.

The current document supports model 3b), though doesn't explain it
directly. One ends up deriving this behavior from the details in the
document.

Do I have this right?

Thomas

---

From: Radia Perlman <[email-masked]>
Date: Wed, 20 Mar 2013 19:22:15 -0700

It's actually quite simple.  All the transit RBs are supposed to be
FGL-safe before you introduce FGL frames.

If you follow that rule, things are very simple...there can be VL edges and
FGL edges, and it will work just fine.
Let's say that R3 and R4 are VL-only, and R1 and R2 can be FGL edges.  R3
and R4 can send packets through the campus to each other, and R1 and R2 can
send packets to each other through the campus.  An FGL multicast packet
will not reach R3 or R4 because R3 or R4's neighbor will be FGL-safe and
will discard the frame (that rule is in the draft).  But the FGL multicast
will reach all FGL edges, which is what you want anyway.

The case that isn't supposed to happen, but we do at least specify what
happens if it does, is when there are transit non-FGL-safe RBridges, and
someone starts sending FGL packets.  For instance, suppose R3 is not
FGL-safe. The design in the spec results in having the campus possibly
partition as a result of that.  For example, if FGL edges R1 and R2 want to
send FGL frames to each other, and R3 happens to be on the path between
them, then tough luck...FGL frames will be discarded.

As I said, we had a different design before that had FGL RBridges compute
Djkstra in two different ways depending on whether the destination nickname
was an FGL edge or not.  If the destination was NOT an FGL edge, then
compute Dijkstra normally.  If it was an FGL edge, then discard the LSPs of
all non-FGL-safe RBridges before computing Dijkstra, so that all FGL-safe
RBridges would compute paths to FGL edges that never went through any
non-FGL-safe RBridges.  So VL packets would work just fine always.  And FGL
packets (unicast and multicast) would work find as long as ANY path
consisting of all FGL-safe RBridges existed.

There was (at least) one person who thought that  design was too
complicated, and that with the assertion that all the transit RBs could
"easily" be upgraded to be FGL-safe, there was no reason to worry about
having the case of transit VL RBridges work gracefully....that we should
just assume that all the transit RBridges get upgraded to FGL-safe, and the
forwarding table computation wouldn't need to do the special thing.  The
downside of the current design is, as I said, that if the least cost path
between FGL edges R1 and R2 happens to go through non-FGL-safe R3, then
tough luck...packets get dropped.  But again, if it's trivial to upgrade
all existing implementations to be FGL-safe, then this seems like the right
way to go.

Sometimes things can get more easily cleared up with a phone call...I'd be
happy to discuss it with you by phone, Thomas, if you still find this
confusing.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 22 Mar 2013 11:06:29 -0400

Hi Thomas,

There are basically three types of migration / interoperability in the
draft, which I will label 0, 1, and 2.

0 is the smoothest and most complete migration, where you upgrade all
VL TRILL switches to FGL-safe before turning on FGL traffic. In this
case, Section 5 of the draft never applies.
     However, there is silicon that can't be upgraded to FGL-safe and,
in any case, you might have misconfiguration resulting in a mixed
campus.

2 is the other end of the spectrum and corresponds to step (B) in
Section 5.1 of the draft. This cuts off data communication between VL
TRILL switches and FGL-safe TRILL switches if there are any FGL-edges
in the campus. Safe but perhaps ugly and not so useful; however, if
your silicon will not support 0 or 1, you are forced to go with 2 or
be unsafe (for example, possibly leak data into wrong data label
violating security, etc.).

1 is perhaps the most interesting. If your silicon can't support 0 but
can support step (A) in Section 5.1, then going with 1 is much better
than going with 2. With 1 you have campus wide VL connectivity
including such things as enabling peripheral islands of VL to
communicate across an FGL-safe core. And you have full FGL
connectivity in a contiguous FGL island. If you misconfigure your
network so that you have more than one contiguous FGL island, of
course, they can't talk to each other with FGL. But, as I say, you do
have campus wide VL connectivity.

I think Radia in her answer was concentrating more on case 0. I'll
talk a bit more below about 1 and 2.

> FGL-safe, but all RBs would operate in VL-only mode.

This case would likely be an intermediate state using the "two phase"
migration strategy 0 of changing your VL TRILL switches to FGL-safe
and then, when they are all upgraded, starting to configure FGL ports
on TRILL switches that support such ports. As I say, this migration
strategy assumes that all your VL TRILL switches can be upgraded to
FGL-safe, which might not be true.

(I'm still not sure why you insist on calling what the FGL-safe
RBridges are doing in this case a "mode". I would say that, looking at
their range of possible operation, they are operating in a sub-set of
that range, but it isn't a mode. There is no mode switch.)

> aren't used. So I'd just rule this case out of scope.

If a configuration is physically realizable, you should assume it will
happen and take that into account, so I'm not sure what you mean by
"out of scope".

> Well, except an operator needs to be aware of this restriction, so

I guess. It is certainly a somewhat bizarre state for a campus to be
in. The VL TRILL switches are not doing anything useful. I suppose you
might have something like a bunch of TRILL switches you have just
received that can be configured as VL or as FGL-safe and you hook them
up when they are still configured as VL before you proceed to
reconfigure them as FGL-safe or something.

You are clearly not doing 0.

If the FGL TRILL switches are all contiguous is one island, then it
doesn't much matter for this state whether you are doing 1 or 2. You
at least have full connectivity between your FGL TRILL switches.

If your FGL TRILL switches are not-contiguous, then if you are doing 1
they at least have VL connectivity across the campus and FGL
connectivity within each FGL island, whereas if you are doing 2 each
FGL island has only VL and FGL connectivity within itself.

> This leads to two different problems.

(You mean two different opportunities? :-)

> those two VLANs? Why or why not?

I don't quite understand your questions and, like almost everything,
it depends on whether you are doing 0, 1, or 2 and your topology, at
least whether your FGL-safe TRILL switches are all contiguous, as they
should be, or your campus is misconfigured to have disjoint FGL
islands.

Maybe it is better to look at it from the viewpoint of ports by which
end stations are connected.

Consider VL ports. FGL-safe TRILL switches are supersets of VL TRILL
switches and support VL ports just like VL TRILL switches do. As
explained in Section 3 of the draft (VL versus FGL Label Differences),
VLAN labels are globally significant. Two end stations in VLAN-X that
are attached to VL ports (which could be on any combination of VL or
FGL-safe TRILL switches) can communicate if there is VL connectivity
between the TRILL switches these ports are on. There will always be
such connectivity for 0 and 1. For 2, there will only be such
connectivity if the ports are on TRILL switches that are in the same
island of VL TRILL switches or island of FGL-safe TRILL switches,
since 2 cuts data connectivity between VL and FGL-safe.

That's for VL ports. If you are talking FGL ports, things are
different. The end stations can be in VLAN-X and VLAN-Y, which could
be the same or different, but only have connectivity if they are on
FGL ports that map their VLAN to the same fine grained label and the
two FGL-safe TRILL switches those ports are on have FGL connectivity.
Such FGL connectivity will always exist for 0 but will exist for 1 or
2 only if the FGL-safe TRILL switches are in the same FGL island. A
well configured campus will have only one FGL island.

> transition approach when deploying FGL.

Well, VL TRILL Data packets and FGL TRILL Data packets are ships in
the night. The VL and FGL label spaces are disjoint...

> directly. One ends up deriving this behavior from the details in the

Yes, the ingress TRILL switch decides whether to ingress as a VL or
FGL TRILL Data frame, although if the ingress TRILL switch is a VL
TRILL switch, it can't choose FGL, of which it is ignorant. I'm not
sure what "conceptually runs two different [SPF] instances" means.
Each TRILL switch see exactly the same campus topology and exactly the
same link costs as every other TRILL switch and each runs SPF once.

If you are going with 0, no problems arise.

If you are going with 1, the very high FGL-safe to VL link cost causes
least cost paths to avoid such links which, in the relevant cases,
causes such paths to avoid VL TRILL switches if possible.

If you have to fall back to 2, the campus is effectively separated
into disjoint islands of VL or FGL-safe without data connectivity
between them.

Thanks,
Donald