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

Radia Perlman <radiaperlman@gmail.com> Wed, 20 March 2013 20:08 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E83321F8265 for <trill@ietfa.amsl.com>; Wed, 20 Mar 2013 13:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivB90oZ00g7B for <trill@ietfa.amsl.com>; Wed, 20 Mar 2013 13:08:57 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 35FE921F8546 for <trill@ietf.org>; Wed, 20 Mar 2013 13:08:51 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id fr10so3769232lab.12 for <trill@ietf.org>; Wed, 20 Mar 2013 13:08:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8Ucna0oFxzWY5clzf6201QH13Y0yJjOxzlOHV+TicSo=; b=v/syy824FBevjk900a9O7TCUIHM+ugDtGYWZveXVbgHdw9Xf2fBWJAUzOdJxU5kI7O mKfZzYkD94lNXtRglPUCBScCDaCKukYXHdzHyQMpJaams/a6pXtmxBfz/UGcXVTr1x4Z k+METrS+1Yn4UWLtnz34E65fD6hyacjDDc42vLpVQ6uhNBbI3qpinCmSBXTGOxpzuqqi Y/LPkHGMvd+y532fbJoz6rznnqa9bbXx15EA06bx36n06/elNG68joW1Ux9YbkzL5KeG Ef1VuVjuLK4IHuABmmCHoVXtTeXjQI/gRghdtuJuGQkcM9deLc99VbzidalWyYmjFvjW 02ig==
MIME-Version: 1.0
X-Received: by 10.112.8.164 with SMTP id s4mr894753lba.106.1363810130084; Wed, 20 Mar 2013 13:08:50 -0700 (PDT)
Received: by 10.112.137.161 with HTTP; Wed, 20 Mar 2013 13:08:49 -0700 (PDT)
In-Reply-To: <201303201859.r2KIxJ32017742@cichlid.raleigh.ibm.com>
References: <201303201859.r2KIxJ32017742@cichlid.raleigh.ibm.com>
Date: Wed, 20 Mar 2013 13:08:49 -0700
Message-ID: <CAFOuuo5nwwtEwJSqXZqOQ6tvxkbn+6jMimJVr9OMfwcSSFxfBw@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: Thomas Narten <narten@us.ibm.com>
Content-Type: multipart/alternative; boundary=e0cb4efe293c58528704d860ca1a
Cc: trill@ietf.org
Subject: Re: [trill] FGL "safe" mode in fine labels
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2013 20:08:58 -0000

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 <narten@us.ibm.com> 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
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>