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

[Radia Perlman <[e-mail]>]

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





On Wed, Mar 20, 2013 at 6: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?
>
> 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
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>