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

[Donald Eastlake <[e-mail]>]

Hi Thomas,

On Wed, Jul 18, 2012 at 2:47 PM, Thomas Narten <[e-mail]> 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
wrong.

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

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Thomas