Re: [trill] I-D Action: draft-ietf-trill-clear-correct-05.txt

Donald Eastlake <> Thu, 19 July 2012 00:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1339E11E81DE for <>; Wed, 18 Jul 2012 17:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.517
X-Spam-Status: No, score=-103.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xwo93IG7kcrQ for <>; Wed, 18 Jul 2012 17:57:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5F08911E80EB for <>; Wed, 18 Jul 2012 17:57:09 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so2461686ggn.31 for <>; Wed, 18 Jul 2012 17:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UlVGY+43h03lb7xSy31hFKAlQ2iOf7r2XC68Jf4LNdY=; b=oKv8wdBNQYi1/rQNu7gLlAxyReWtpIhGkJtEoZeU5qthONiDehQwFRPGoSpM7LSC+w 8duDORF+uF61dgrClzpsrG4vOFUrwZgjN+tDll3YqbHQRXXe4KejjqtgvQWglzJSZOb7 71HPCey9Y/FABp3R9Bxp3dC8rZQKERLR2FCiZuf3j+wnrpHn8MPOznz1GrLnRo9kF+aZ YQcJ0xs0sorBMleojno17qvkJ/TCvDdM4OHHubrjgt0HxyyWGKJbHcGk32Tx+n97dDQW oR8Gv1IGpapfD4SYaJcX2YQFjXDvcJltLTkYkiyzRhn0foEZnnB4LVwJSd73IYkKoWC7 Z6qQ==
Received: by with SMTP id ip8mr3766753igc.50.1342659480657; Wed, 18 Jul 2012 17:58:00 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 18 Jul 2012 17:57:40 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Donald Eastlake <>
Date: Wed, 18 Jul 2012 20:57:40 -0400
Message-ID: <>
To: Thomas Narten <>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: [trill] I-D Action: draft-ietf-trill-clear-correct-05.txt
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, 19 Jul 2012 00:57:10 -0000

Hi Thomas,

On Wed, Jul 18, 2012 at 2:47 PM, Thomas Narten <> wrote:
> Hi Donald.
>> This draft has relatively small changes that are responding to a
>> Routing Directorate review. The most significant of these is that it
>> clarifies that packets are not forwarded through overloaded RBridges.
>> If you have a problem with any of these changes, please tell me or
>> post to the list.
> I took the above as an opportunity to review what the various TRILL
> specs say about handling "overload" situations.
> I gather that an overloaded RB sets the overload bit in its IS-IS
> advertisement to indicate "I have problems and may not work right".

Well, it really just means that the link state database has
overflowed. Thus the RBridge can't hold it all and anything that it
would calculate from that database, such as least cost paths, could be

> OK. But what exactly are other RBs supposed to do with this info?

Except as specified in this draft, they should do what ISO/IEC
10589:2002 (the base IS-IS standard) says. ISO 10589 only talks about
unicast data but has appropriate provisions so that if there are only
scattered Intermediate Systems in overload, those ISs can still
originate and terminate packets but can't act as transit nodes.

> I would assume that for correctness/consistency, the safest thing to
> do is simply remove the RB from the topology and pretend it doesn't
> exist. i.e, stop using it or trying to forward traffic through
> it. Yes, this may result in suboptimal routes (or worse), but at least
> you'll get consistent behavior. If TRILL continues to forward traffic
> through RBs that aren't working right, you'll likely see more
> random/intermittent problems that are hard to debug/diagnose.

If you remove it from the topology, then no packets can reach and
possibly none can be originated by it. This makes maintenance (like
logging into it and re-booting it) harder. So it stays in the topology
and frames can be routed to it, but least cost paths are not allowed
that would go through it. (As I say, this only works for scattered
overloaded ISs. If you had a dense cluster of them, those on the
inside of the cluster, at least, would be unable to communicate.)

> That said, the clear-correct draft does say if the AF is the only RB
> connected to a particular VLAN at an edge, if you remove that RB from
> TRILL, the VLAN becomes unreachable. So it says don't do that.
> But going through the various spec, the published RFCs don't seem to
> say anything about the overload bit. (I didn't do an exhaustive
> search, but searching for the string "overload" in the RFCs shows
> almost nothing.)
> Where is the TRILL behavior wrt to using the overload flag documented?

As I say, the base behavior is the ISO standard. The Clarifications
and Corrections draft extends that  to cover multi-destination frames,
for example.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> Thomas