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

[Donald Eastlake <[e-mail]>]

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.

On Wed, Mar 20, 2013 at 9:03 PM, Thomas Narten <[e-mail]> wrote:
> 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?

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

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

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
> they aren't surprised.
>
> Does this make sense?

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.

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

(You mean two different opportunities? :-)

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

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.

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

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

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

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
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Do I have this right?
>
> Thomas