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

[Radia Perlman <[e-mail]>]

The document does formally define , right in the introduction, and quite
clearly I believe, what "FGL-safe" means.  It does not mean that you must
be able to ingress or egress FGL frames.

And to repeat...the difference between FGL-safe and "fully understanding
FGL" is that it is fine to be a transit RBridge with FGL-labeled frames
even though you don't parse the FGL label, and can't ingress-egress them.

your comment:

>>Actually, all they need to know is whether there is *one* RB that
>>*doesn't* understand FGL. If one such RB exists, everyone just
>>operates in VL mode. (Right?)

No!  There isn't any mention in the document of "operating in VL mode",
whatever it is you might mean by that.

If R1 is FGL-safe, and if R1's neighbor R2 does not claim to be FGL-safe,
then R1 does not forward FGL frames to R2.  R1 does not do anything
different if some non-neighbor of R1, say R3, is not FGL-safe.

And when I said that the document could be improved editorially, I was just
saying that pretty much any document could be improved editorially.  I
think the document is sufficiently clear.  It's written more from "this is
exactly how you behave as an RBridge" rather than tutorially, and it's
longer than probably necessary, and indeed it was rewritten from the more
tutorial style (that I'd written most of) because of someone complaining
that there was too much emphasis on explaining the transition.  With
editorial stuff, we'll never ship anything if we wait until everyone is
happy with the style, because everyone has different style preferences.
 The real question is whether it's accurate and sufficiently clear, which I
believe it is.  I believe it is clearer than most IETF RFCs.

Radia






On Wed, Mar 20, 2013 at 1:32 PM, Thomas Narten <[e-mail]> wrote:

> Hi Radia.
>
> > 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"
>
> I understand that, but what is the value in writing a standard with
> that sort of description? The FGL document should be about what you
> have to do to be compliant and how to get interoperabilty. "Not doing
> anything bad" doesn't seem like the right way to say that...
>
> > as opposed to being able to understand FGL labels.
>
> Could someone then please layout what capabilities an "FGL safe" RB
> has that a "fully compliant" RB does not? What is the difference?
> Better yet, point me to text in the document that explains that.
>
> > 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.
>
> Actually, all they need to know is whether there is *one* RB that
> *doesn't* understand FGL. If one such RB exists, everyone just
> operates in VL mode. (Right?)
>
> If that is what the intended behavior is, why can't the document just
> come out and clearly say that?
>
> > 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 find this sort of definition somewhat maddening.
>
> What we need to clearly describe is when an RB is capable of
> supporting FGL (fully) and when can FGL be enabled on a TRILL campus
> (and then on which RBs).  And will this be clearly understood by an
> operator trying to actually use and deploy the functionality?
>
> > 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.
>
> Great. But it's really frustrating when folk start saying "I agree the
> document isn't so good, but we need to publish it anyway" with the
> implication being "no thanks for taking the time to review and trying
> to make the document better".
>
> Thomas
>
>