Subject: [trill] A tweak to option 2, if it's hard to upgrade VL guys to FGL-safe

From: Radia Perlman <[email-masked]>
Date: Thu, 31 Jan 2013 13:47:43 -0800

The other thread was getting a bit long, so I'm changing the subject line,
since here I'm proposing a tweak to option 2 that will make it less
restrictive.  To review, option 2 as originally proposed had this property:

>>With option 2, a VL guy cannot even be at the edge of a network with FGL
links unless it is upgraded to
>>FGL-safe AND advertises that it is FGL-safe.  Option 2 says a VL guy is
completely ostrasized once
>>FGL-labeled links are introduced.  There is NO coexistence of VL guys and
FGL-guys once FGL-links are
 >>advertised.

Here is the proposed tweak:

An FGL-safe guy has two choices of what to do with a VL neighbor (once FGL
links are advertised)

a) ostrasize the VL neighbor completely (as was in option 2)
b) advertise a very high cost to the VL neighbor AND ALSO discard any FGL
frames that would be forwarded to that VL neighbor.

If an FGL-safe guy is capable of differentiating between FGL and VL
frames...forwarding VL but discarding FGL to a VL neighbor, then this would
allow VL guys to be at the edge and successfully talk across an FGL core.

If an FGL-safe guy is not capable of differentiating between FGL and VL
frames, then the VL guy will be ostrasized.

As for transit...if a VL guy is in the core, its FGL neighbors will report
such high costs to it that if there is any FGL path, that will be the one
that is chosen, and if there isn't, then you're no worse off than if the VL
guy were completely ostrasized....it will look like there is a path, but
FGL packets will be lost on the path.

And of course, you shouldn't have the VL guy be the root of a multicast
tree, since link costs to it won't avoid it being on the path between FGL
guys.

Radia