[trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

[Radia Perlman <[e-mail]>]

I'm going to summarize three options for phasing-in FGL, and explain the
tradeoffs, to help people have informed opinions about the implications of
the three approaches.  There are infinite variations, of course, but as I
said, I'll describe three main ones.

Option 1:  Original draft, no changes.  There are two types of RBridges.
The first type is "VL" which only understands VLAN tags, and have unknown
and possibly dangerous behavior when they receive an FGL-labeled packet.
(e.g., decapsulate a packet onto a link where it is not allowed, or
mistakenly prune a multicast so it does not reach everywhere it should).
The second type is "FGL".  FGL guys need to do two things: 1) understand
FGL tags and do the right thing with them, and 2) ostrasize VL
guys...meaning that an FGL guy refuses to form an adjacency with a VL guy.
 This option is very simple for implementers of FGL, but the implication is
that you have to upgrade your entire campus to FGL at once.  There is no
coexistence.

Option 2: Two types of RBridges, but the 2nd type is different from option
1.  VL guys of course are the same as in option 1...they cannot be trusted
with FGL frames. The second type I will call "FGL-safe". An FGL-safe
RBridge must advertise in its LSP that it is FGL-safe, and it must not "do
anything bad" with FGL frames, meaning that it is allowed to ignore pruning
of FGL (or even VL frames) entirely...it just can't falsely drop FGL
frames.  And it must not decapsulate an FGL frame onto a link for which
that FGL frame doesn't belong. In this option, all RBridges must be
upgraded to FGL-safe, but it need not happen instantaneously...it's fine to
mix FGL-safe RBridges with VL RBridges...it's just not safe to inject FGL
frames yet.  Once all the RBridges have been upgraded to be FGL-safe, then
edge RBridges can start announcing they are connected to an FGL link, and
can start injecting FGL packets.  It is considered a misconfiguration if
you start injecting FGL frames before all the RBridges are upgraded to
FGL-safe, so an additional chore for an FGL-safe RBridge R1 is to examine
LSPs, and if any RBridge claims to be attached to an FGL link, then R1 must
ostrasize any VL neighbors.  (don't start ostrasizing VL guys until it is
necessary because of actually starting to use FGL frames, in other words).
This option is more work for the upgraded RBridges than option 1, and there
still isn't good coexistence with VL guys long-term (as option 3 will), but
it does allow upgrading RBridges one by one in a working campus without
causing disruption.

Option 3: Two types of RBridges.  VL, of course, is the same as in options
1 and 2.  This option makes FGL guys do more work, but allows maximal long
term coexistence of VL and FGL guys. In this option, FGL guys calculate
unicast paths to FGL edge guys that avoid any VL guys, and calculate at
least one FGL-friendly multicast tree that also avoids any VL guys. So
let's say R1 is an FGL guy.  R1 discards all LSPs from VL guys (ones that
don't advertise FGL capability in their LSP), when calculating paths to
other FGL RBridges. Then R1 calculates paths to the VL guys using all LSPs.
 Likewise, when calculating an FGL-friendly tree, R1 calculates a tree
through only FGL guys.   This option is more work for the upgraded RBridges
(because they have to calculate Dijkstra in two different ways, one for
reaching VL guys, and one for reaching FGL guys).  However, it does allow
having long-term coexistence with VL guys.  For instance, you could forever
keep some VL edge RBridges that communicate just fine through an FGL core.
 They can stay there forever, and still be able to communicate through the
core to all the links attaching to their VLAN.