Subject: [trill] TRILL deployment

From: devon ietf <[email-masked]>
Date: Thu, 26 May 2016 12:31:23 +0530

why is trill not so widely deployed. It's been around for several years and
xSTP protocols
are really bad, then too i don't see customers adopting TRILL as widely.
what's wrong ?

---

From: Jon Hudson <[email-masked]>
Date: Thu, 26 May 2016 00:50:49 -0700

Main issue that I know from customers is the lack of consistent tools to deep dive debug it. 

Jon

> On May 26, 2016, at 12:01 AM, devon ietf <[email-masked]> wrote:
> 
> why is trill not so widely deployed. It's been around for several years and xSTP protocols
> are really bad, then too i don't see customers adopting TRILL as widely. what's wrong ?
> 
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 26 May 2016 21:12:51 -0400

> Main issue that I know from customers is the lack of consistent tools to deep dive debug it.

It seems to me that this is a lack of user tools, not any inherent
problem with TRILL. TRILL has:
TRILL OAM (continuity fault management): RFCs 6905, 7174, 7455, 7784
MIBs: RFCs 6850, 7784
Supports BFD: RFC 7175
Has performance monitoring specified: RFC 7456

In addition, if a management station peers as an RBridge, it would
have direct access to the link state data base.

So I really don't see why there should be a problem with implementing
good TRILL debugging tools.

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

---

From: Jon Hudson <[email-masked]>
Date: Fri, 27 May 2016 04:25:53 -0700

110% agree

It's the vendor implemented tools that are primarily at issue. 

Jon

> On May 26, 2016, at 6:12 PM, Donald Eastlake <[email-masked]> wrote:
>