Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

Olen Stokes <> Thu, 31 January 2013 22:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A12721F8505 for <>; Thu, 31 Jan 2013 14:00:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wPozOyJNqmIU for <>; Thu, 31 Jan 2013 14:00:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 80AB621F8440 for <>; Thu, 31 Jan 2013 14:00:24 -0800 (PST)
Received: from ([]) by ([]) with mapi; Thu, 31 Jan 2013 14:00:24 -0800
From: Olen Stokes <>
To: Radia Perlman <>, "Tissa Senevirathne (tsenevir)" <>
Date: Thu, 31 Jan 2013 14:00:22 -0800
Thread-Topic: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)
Thread-Index: Ac3/8RGYMXHAf2d5T9mBg4ykeRF8PgACGvPw
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB50276CA7B6A4DUSEXCHANGEc_"
MIME-Version: 1.0
Cc: Anoop Ghanwani <>, Ayan Banerjee <>, Sam Aldrin <>, "" <>, Donald Eastlake <>, Jon Hudson <>
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: Thu, 31 Jan 2013 22:00:28 -0000

Thanks for consolidating these topics.  Please see two [OLS] comments in line...

From: [] On Behalf Of Radia Perlman
Sent: Thursday, January 31, 2013 3:24 PM
To: Tissa Senevirathne (tsenevir)
Cc: Anoop Ghanwani; Ayan Banerjee; Sam Aldrin;; Donald Eastlake; Jon Hudson
Subject: Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

Tissa said:
>> how can you make sure all of the so called "Safe FGL" have consistent behavior

"Safe FGL" need not all have the same behavior as each other...they just have to do "nothing bad" with an FGL frame.  It's worth summarizing (again) what it means to be "FGL-safe", which allows you to coexist safely with FGL frames.  To be FGL-safe you must do the following:

a) unicast: you MUST NOT drop a packet because of seeing the unrecognized FGL tag.  You also MUST NOT get confused and do flow hashing improperly (choosing different paths for packets for the same flow).

b) multicast pruning: it's OK not to do pruning at all, or to actually look at all 24 bits of the FGL and prune as a proper FGL guy would do.  But an example of what you canNOT do is look at the first 12 bits of FGL, pretend it's the same as VL, and delete the multicast packet because nobody downstream is listening to that 12 bit VL value

[OLS]: I believe that there is still FGL-based pruning and multicast pruning.  It should be OK to do FGL-based pruning and not do multicast pruning.  For FGL-based pruning, I agree that a FGL-safe node cannot look at the first 12 bits of FGL and just "pretend it's the same as VL".  However, it should be possible for the control plane to determine all FGL's that have the same first 12 bits of FGL.  Such a control plane should be able to set up FGL-based pruning for each leg of a D-Tree based on the existence of listeners downstream belonging to the collection of FGL's with the same first 12 bits.

c) egress of either unicast or multicast:  you MUST NOT egress an FGL frame onto a link that is not supposed to get that FGL value

d) you have to advertise that you are FGL-safe...otherwise other RBs will assume you are VL ("FGL-unsafe")

Also, TIssa said:
>>Do you agree if we say, FGL will always be core of the network, and VL will be at the edge of the network ?

With option 2, a VL guy cannot even be at the edge of a network with FGL links unless it is upgraded to FGL-safe AND advertises that it is FGL-safe.  Option 2 says a VL guy is completely ostrasized once FGL-labeled links are introduced.  There is NO coexistence of VL guys and FGL-links. The only kinds of coexistence in option 2 are:

a) VL and FGL-safe RBridge, but no actual FGL links yet.
b) FGL-safe guys, even if some of them don't really understand FGL, but just don't do "anything bad" with it, and FGL frames.

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.

[OLS]: Just to double check...  Following step #4 above, FGL-safe RBridges on the edge should still be able to send/receive VL frames.  This allows migration for devices on the edge that can be made FGL-safe but cannot ingress/egress FGL frames.

Also, Tissa said:
>>what about some devices who are not "safe FGL" and so on, are we saying do not buy no safe FGL devices, if you do that you cannot get FGL interop ?

If it's important to have VL guys as transit, and they cannot be upgraded to FGL-safe because upgrading requires a hardware change (it involves parsing data packets), then we are stuck with option 3.  In option 3, we can forever have VL guys at the edge speaking through an FGL-safe or full-FGL core.  In option 2, as I said, there is no coexistence of VL guys, even at the edge, once FGL links are introduced.  In option 2, a VL guy, even at the edge, will be ostrasized completely once anyone advertises connectivity to an FGL link.

I personally like option 2, because it's simple, but as Einstein said "make things as simple as possible, but no simpler".  We have to make sure that everyone understands the implications of option 2, and can live with them.  To summarize again (since there seems to be some confusion about what the implications of option 2 are),

If we can upgrade all existing VL implementations to FGL-safe through software upgrade only, then option 2 provides smooth migration by changing ALL RBridges (edge as well as transit) to FGL-safe, and only after ALL of them are upgraded, then FGL-labeled links can be introduced.  If there are any remaining VL guys once FGL-labeled links are introduced, the VL guys are ostrasized, even if they are just at the edge.

If we canNOT upgrade all existing VL to FGL-safe, AND if it's important to be able to mix VL guys into a network with FGL frames (say, having VL guys at the edge), then option 3 allows this.

So hopefully everyone understands the implications of option 2 fully before voting.  As I said, I don't know about whether there are VL chips that would require a hardware upgrade to become FGL-safe.  Assuming there are none, then I'm quite happy with option 2.   And actually, it looks like people are converging on option 2 (though I hope it's based on fully understanding option 2).  Now is the time for people to speak up, that know of problems this would cause...for instance, needing to have non-upgradable VL guys at the edge for a long time.