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

[Radia Perlman <[e-mail]>]

I never get too excited about what words are used, but the terminology
"FGL-safe" is intended to mean "doesn't do anything bad with FGL traffic"
as opposed to being able to understand FGL labels.
So, indeed, "FGL-capable" would, I believe, evoke a different image from
"FGL-safe", since the reader would assume from the word "FGL-capable", that
it would actually be able to parse FGL labels.  And indeed, it doesn't
matter to R1 whether distant RBridge R2 is FGL-capable...the only time R1
needs to do something different is if R2 is not FGL-safe.

Whether R2 is indeed "FGL-capable" is really only a local matter...whether
it can sink or source FGL traffic, so obviously if it isn't FGL-capable, it
won't actually claim to be connected to an FGL link.

I thought the writeup that I'd done explaining the four steps, that you
quoted:


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

was clearer than what is in the current draft, but I didn't argue since I
believe the current draft does have that technical behavior.  Most drafts
could be written more clearly, but we really are way overdue for issuing
this, and I wouldn't want to delay it because of editorial issues with the
draft.

Radia




On Wed, Mar 20, 2013 at 11:59 AM, Thomas Narten <[e-mail]> wrote:

> I spent some time rereading the current fine labels draft
> (draft-ietf-trill-fine-labeling-05.txt) and the January email thread
> on "safe mode" (Re: [trill] Explaining three options for upgrading to
> FGL (fine-grained-labeling)).
>
> But I'm still not sure I understand...
>
> What exactly is "FGL-safe mode"? I see the definition in the document,
> but it doesn't explain at a high level what this mode is intended to
> do. I.e., what the principles are. I.e., what does it mean for a TRILL
> campus (as opposed to an individual RB)?
>
> Is "safe" mode just another word for "FGL capable", i.e., the
> implementation is capable of fully supporting FGL?
>
> Or is there a broader definition for "capable"? (Some other messages
> seem to suggest this) If so, what is the difference?
>
> Finally, what is the migration path from VL to FGL in a real
> network?
>
> Back in January, Radia said
> (http://www.ietf.org/mail-archive/web/trill/current/msg05632.html):
>
> > 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.
>
> From the above, I conclude that there is no FGL traffic and no actual
> usage of FGL capabilities until step 4.  That makes sense to me, but
> this is not explained clearly in the current draft. Indeed, it's
> pretty easy to conclude from the draft that an RB operates in both FGL
> and VL mode at the same time from the way the behavior is described
> (often talking about an RB having some links doing FGL and some doing
> VL).
>
> PS, to me "FGL safe" doesn't seem like the right term. Wouldn't "FGL
> capable" be more accurate, and then distinguish between an
> implementation fully supporting FGL (i.e., is "capable") vs. that
> capability being enabled operationally? That would seem to more
> clearly reflect what (I think) is the intended behavior.
>
> Thomas
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>