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

From: [email-masked]
Date: Mon, 16 Jul 2012 16:10:18 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title           : TRILL: Clarifications, Corrections, and Updates
	Author(s)       : Donald Eastlake
                          Mingui Zhang
                          Anoop Ghanwani
                          Vishwas Manral
                          Ayan Banerjee
	Filename        : draft-ietf-trill-clear-correct-05.txt
	Pages           : 30
	Date            : 2012-07-16

Abstract:
   The IETF TRILL (TRansparent Interconnection of Lots of Links)
   protocol provides least cost pair-wise data forwarding without
   configuration in multi-hop networks with arbitrary topology and link
   technology, safe forwarding even during periods of temporary loops,
   and support for multipathing of both unicast and multicast traffic.
   TRILL accomplishes this by using IS-IS (Intermediate System to
   Intermediate System) link state routing and by encapsulating traffic
   using a header that includes a hop count. Since the TRILL base
   protocol was approved in March 2010, active development of TRILL has
   revealed errata in the original RFC 6325 and some cases that could
   use clarifications or updates.

   RFC 6327 and RFC 6439 provide clarifications and updates with respect
   to Adjacency and Appointed Forwarders. This document provides other
   known clarifications, corrections, and updates to RFC 6325, RFC 6327,
   and RFC 6439.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-trill-clear-correct-05

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-trill-clear-correct-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 16 Jul 2012 21:12:39 -0400

Hi,

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.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Mon, Jul 16, 2012 at 7:10 PM,  <[email-masked]> wrote:
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill

---

From: Thomas Narten <[email-masked]>
Date: Wed, 18 Jul 2012 14:47:39 -0400

Hi Donald.

> If you have a problem with any of these changes, please tell me or

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

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

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.

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?

Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 18 Jul 2012 20:57:40 -0400

Hi Thomas,

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

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

> 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