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

[Radia Perlman <[e-mail]>]

Tissa said:
>> how can you make sure all of the so called "Safe FGL" have consistent
behavior

"Safe FGL" need not all have the *same* behavior as each other...they just
have to do "nothing bad" with an FGL frame.  It's worth summarizing (again)
what it means to be "FGL-safe", which allows you to coexist safely with FGL
frames.  To be FGL-safe you must do the following:

a) unicast: you MUST NOT drop a packet because of seeing the unrecognized
FGL tag.  You also MUST NOT get confused and do flow hashing improperly
(choosing different paths for packets for the same flow).

b) multicast pruning: it's OK not to do pruning at all, or to actually look
at all 24 bits of the FGL and prune as a proper FGL guy would do.  But an
example of what you canNOT do is look at the first 12 bits of FGL, pretend
it's the same as VL, and delete the multicast packet because nobody
downstream is listening to that 12 bit VL value

c) egress of either unicast or multicast:  you MUST NOT egress an FGL frame
onto a link that is not supposed to get that FGL value

d) you have to advertise that you are FGL-safe...otherwise other RBs will
assume you are VL ("FGL-unsafe")

---------
Also, TIssa said:
>>Do you agree if we say, FGL will always be core of the network, and VL
will be at the edge of the network ?

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-links.
The only kinds of coexistence in option 2 are:

a) VL and FGL-safe RBridge, but no actual FGL links yet.
b) FGL-safe guys, even if some of them don't really understand FGL, but
just don't do "anything bad" with it, and FGL frames.

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.


----
Also, Tissa said:
>>what about some devices who are not "safe FGL" and so on, are we saying
do not buy no safe FGL devices, if you do that you cannot get FGL interop ?

*If* it's important to have VL guys as transit, and they cannot be upgraded
to FGL-safe because upgrading requires a hardware change (it involves
parsing data packets), then we are stuck with option 3.  In option 3, we
can forever have VL guys at the edge speaking through an FGL-safe or
full-FGL core.  In option 2, as I said, there is *no coexistence* of VL
guys, *even at the edg*e, once FGL links are introduced.  In option 2, a VL
guy, even at the edge, will be ostrasized completely once anyone advertises
connectivity to an FGL link.

I personally like option 2, because it's simple, but as Einstein said "make
things as simple as possible, but no simpler".  We have to make sure that
everyone understands the implications of option 2, and can live with them.
 To summarize again (since there seems to be some confusion about what the
implications of option 2 are),

If we can upgrade all existing VL implementations to FGL-safe through
software upgrade only, then option 2 provides smooth migration by changing
ALL RBridges (edge as well as transit) to FGL-safe, and only after ALL of
them are upgraded, then FGL-labeled links can be introduced.  If there are
any remaining VL guys once FGL-labeled links are introduced, the VL guys
are ostrasized, *even if they are just at the edge.*

If we canNOT upgrade all existing VL to FGL-safe, AND if it's important to
be able to mix VL guys into a network with FGL frames (say, having VL guys
at the edge), then option 3 allows this.

So hopefully everyone understands the implications of option 2 fully before
voting.  As I said, I don't know about whether there are VL chips that
would require a hardware upgrade to become FGL-safe.  Assuming there are
none, then I'm quite happy with option 2.   And actually, it looks like
people are converging on option 2 (though I hope it's based on fully
understanding option 2).  Now is the time for people to speak up, that know
of problems this would cause...for instance, needing to have non-upgradable
VL guys at the edge for a long time.

Radia