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

Thomas Narten <narten@us.ibm.com> Wed, 20 March 2013 21:19 UTC

Return-Path: <narten@us.ibm.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 E219511E80F2 for <trill@ietfa.amsl.com>; Wed, 20 Mar 2013 14:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 EpdMAHTMxS97 for <trill@ietfa.amsl.com>; Wed, 20 Mar 2013 14:19:36 -0700 (PDT)
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6CF11E80E7 for <trill@ietf.org>; Wed, 20 Mar 2013 14:19:35 -0700 (PDT)
Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <trill@ietf.org> from <narten@us.ibm.com>; Wed, 20 Mar 2013 15:19:35 -0600
Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Mar 2013 15:19:31 -0600
Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id C522B19D804E for <trill@ietf.org>; Wed, 20 Mar 2013 15:19:25 -0600 (MDT)
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2KLJRMW091682 for <trill@ietf.org>; Wed, 20 Mar 2013 15:19:27 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2KLJQPV012432 for <trill@ietf.org>; Wed, 20 Mar 2013 15:19:27 -0600
Received: from cichlid.raleigh.ibm.com ([9.80.19.173]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r2KLJOil012141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Mar 2013 15:19:25 -0600
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id r2KLJL8X003890; Wed, 20 Mar 2013 17:19:21 -0400
Message-Id: <201303202119.r2KLJL8X003890@cichlid.raleigh.ibm.com>
From: Thomas Narten <narten@us.ibm.com>
To: Radia Perlman <radiaperlman@gmail.com>
In-reply-to: <CAFOuuo5Q1at-pn_JPGP-5-WezsKjF6_psDd22_A5sN+sGGq-rw@mail.gmail.com>
References: <201303201859.r2KIxJ32017742@cichlid.raleigh.ibm.com> <CAFOuuo5nwwtEwJSqXZqOQ6tvxkbn+6jMimJVr9OMfwcSSFxfBw@mail.gmail.com> <201303202032.r2KKWOMj030163@cichlid.raleigh.ibm.com> <CAFOuuo5Q1at-pn_JPGP-5-WezsKjF6_psDd22_A5sN+sGGq-rw@mail.gmail.com>
Comments: In-reply-to Radia Perlman <radiaperlman@gmail.com> message dated "Wed, 20 Mar 2013 14:03:39 -0700."
Date: Wed, 20 Mar 2013 17:19:21 -0400
X-TM-AS-MML: No
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13032021-2876-0000-0000-00000689DA41
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 21:19:38 -0000

Radia,

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

Operating in "VL mode" (to me) means you don't know anything about FGL
and operate as described in RFC 6325 et al. I.e., the base mode of
operation for TRILL. I think it's useful to define a term like "VL
mode" to describe that behavior to distinguish it from RBs that have
somehow enabled and are using FGL. 

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

The above says to me that you now have a TRILL campus where R1 does
process FGL frames and R2 does not. But doesn't that contradict the
model:

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

Or maybe we are having a violent agreement? if we are at step 2)
above, then isn't the entire campus operating in "VL mode"? I.e., at
step 2, no one is sending/receiving/processing FGL frames. (Right?)

It's not until step 3/4 that you see *any* FGL frames being used. And
for that, you can't have *any* RBs still operating only in VL mode -
they *all* have to support FGL.

What is it that I'm not understanding?

Thomas