Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling) Wed, 30 January 2013 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0656821F8B35; Wed, 30 Jan 2013 00:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -96.999
X-Spam-Status: No, score=-96.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WgDBvkDXQXEm; Wed, 30 Jan 2013 00:12:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8EA8E21F8B34; Wed, 30 Jan 2013 00:12:02 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTP id 417C5125FC4D; Wed, 30 Jan 2013 16:12:50 +0800 (CST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 54B05193A682; Wed, 30 Jan 2013 16:13:58 +0800 (CST)
Received: from ([]) by with ESMTP id r0U8BaaB063208; Wed, 30 Jan 2013 16:11:36 +0800 (GMT-8) (envelope-from
In-Reply-To: <>
To: Radia Perlman <>
MIME-Version: 1.0
X-KeepSent: 84D5F30E:ED4AC6D3-48257B03:0026CB28; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <>
Date: Wed, 30 Jan 2013 16:11:39 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-30 16:11:31, Serialize complete at 2013-01-30 16:11:31
Content-Type: multipart/alternative; boundary="=_alternative 002D59F048257B03_="
X-MAIL: r0U8BaaB063208
Subject: Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jan 2013 08:12:04 -0000

In the process of an current TRILL campus migrates smoothly to FGL campus, 
it is possible that the core RBriges are first changed to FGL-RBriges (or 
FGL-safe Rbridges), then some edge Rbridges are changed to FGL. 

During the process of that migration, VL traffic and FGL traffic will exit 
in the TRILL campus simultaneously. Option 3 provides a way for the two 
types of traffic being forwarded in that TRILL campus safely. 

Furthermore, I am not sure that a VL-RBridge can be changed to FGL-safe 
just by updating its software.

So I prefer Option 3, although it seems more complex than Option 2.

Best Regards,
Zhai Hongjun
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 Zhai Hongjun
 Tel: +86-25-52877345

Radia Perlman <> 
2013-01-26 03:00


[trill] Explaining three options for upgrading to FGL 

I'm going to summarize three options for phasing-in FGL, and explain the 
tradeoffs, to help people have informed opinions about the implications of 
the three approaches.  There are infinite variations, of course, but as I 
said, I'll describe three main ones.

Option 1:  Original draft, no changes.  There are two types of RBridges. 
The first type is "VL" which only understands VLAN tags, and have unknown 
and possibly dangerous behavior when they receive an FGL-labeled packet. 
(e.g., decapsulate a packet onto a link where it is not allowed, or 
mistakenly prune a multicast so it does not reach everywhere it should). 
The second type is "FGL".  FGL guys need to do two things: 1) understand 
FGL tags and do the right thing with them, and 2) ostrasize VL 
guys...meaning that an FGL guy refuses to form an adjacency with a VL guy. 
 This option is very simple for implementers of FGL, but the implication 
is that you have to upgrade your entire campus to FGL at once.  There is 
no coexistence.

Option 2: Two types of RBridges, but the 2nd type is different from option 
1.  VL guys of course are the same as in option 1...they cannot be trusted 
with FGL frames. The second type I will call "FGL-safe". An FGL-safe 
RBridge must advertise in its LSP that it is FGL-safe, and it must not "do 
anything bad" with FGL frames, meaning that it is allowed to ignore 
pruning of FGL (or even VL frames) just can't falsely drop 
FGL frames.  And it must not decapsulate an FGL frame onto a link for 
which that FGL frame doesn't belong. In this option, all RBridges must be 
upgraded to FGL-safe, but it need not happen's fine 
to mix FGL-safe RBridges with VL's just not safe to inject 
FGL frames yet.  Once all the RBridges have been upgraded to be FGL-safe, 
then edge RBridges can start announcing they are connected to an FGL link, 
and can start injecting FGL packets.  It is considered a misconfiguration 
if you start injecting FGL frames before all the RBridges are upgraded to 
FGL-safe, so an additional chore for an FGL-safe RBridge R1 is to examine 
LSPs, and if any RBridge claims to be attached to an FGL link, then R1 
must ostrasize any VL neighbors.  (don't start ostrasizing VL guys until 
it is necessary because of actually starting to use FGL frames, in other 
words). This option is more work for the upgraded RBridges than option 1, 
and there still isn't good coexistence with VL guys long-term (as option 3 
will), but it does allow upgrading RBridges one by one in a working campus 
without causing disruption.

Option 3: Two types of RBridges.  VL, of course, is the same as in options 
1 and 2.  This option makes FGL guys do more work, but allows maximal long 
term coexistence of VL and FGL guys. In this option, FGL guys calculate 
unicast paths to FGL edge guys that avoid any VL guys, and calculate at 
least one FGL-friendly multicast tree that also avoids any VL guys. So 
let's say R1 is an FGL guy.  R1 discards all LSPs from VL guys (ones that 
don't advertise FGL capability in their LSP), when calculating paths to 
other FGL RBridges. Then R1 calculates paths to the VL guys using all 
LSPs.  Likewise, when calculating an FGL-friendly tree, R1 calculates a 
tree through only FGL guys.   This option is more work for the upgraded 
RBridges (because they have to calculate Dijkstra in two different ways, 
one for reaching VL guys, and one for reaching FGL guys).  However, it 
does allow having long-term coexistence with VL guys.  For instance, you 
could forever keep some VL edge RBridges that communicate just fine 
through an FGL core.  They can stay there forever, and still be able to 
communicate through the core to all the links attaching to their VLAN.
trill mailing list