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

[Donald Eastlake <[e-mail]>]

Hi Thomas,

On Wed, Mar 20, 2013 at 4: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...

There is transit interoperability and there is ingress/egress
interoperability. FGL-safe is about transit interoperability. This is
important because if you have FGL-unsafe (i.e., VL) TRILL switches in
the campus, then you have to be careful that they never get FGL
packets. If all the switches are FGL-safe, then you don't have to
worry about 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.

An FGL-safe TRILL switch conforms to the list in the Introduction. I
believe the Introduction tries to be somewhat tutorial on FGL-safe and
migration.

The right comparison is FGL-safe with FGL-edge. An FGL-edge TRILL
switch has to be FGL-safe but also has port(s) configured to actually
ingress/egress FGL. So, it is the other way around from what you said.
A "fully compliant" (a term not used in the draft, perhaps what you
mean is "fully capable" but that term isn't used either) FGL TRILL
switch has to be FGL-safe and is also capable of being an FGL-edge.

>> 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?)

There isn't anything anywhere in the draft about any kind of FGL TRILL
switch ever just operating in VL mode. The required behavior to make a
mixed campus safe, as described in Section 5.1 (FGL and VL Mixed
Campus) is that FGL TRILL switches that observe an immediate neighbor
that is VL must take either step (A) or step (B) and, in addition, all
FGL TRILL switches must take step (C) whether or not there are any VL
TRILL switches in the campus.

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

Well, an earlier version of the draft used "Limited FGL" and "Full
FGL" and there was substantial negative feedback and about that.

There isn't really such a thing an "enabling" FGL on a campus or TRILL
switch - although there is such a thing as configuring a TRILL switch
port to ingress/egress FGL - something you presumably can't do if that
capability isn't supported by the TRILL switch port you are trying to
configure. Seems to me it would be possible to have a TRILL switch on
which some ports were capable of FGL ingress/egress and some ports
were not.

If you have sources/sinks of FGL, i.e., FGL-edge TRILL switches,
before all the TRILL switches in the campus are FGL-safe, something
that could always happen, then you may either get sub-optimal routing
or you get data isolation between the FGL and VL TRILL switches,
depending on whether your FGL-safe switches support step (A) or step
(B) in Section 5.1.

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

If there are clarifying editorial changes I don't see why they can't be made.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Thomas