Mostly this draft is just bookkeeping so BFD can use trill's P2MP capabilities. I think there is one issue to consider, though since I've not read all the referenced documents in detail, I'm open to correction as to whether or not this is a real issue. IIRC, BFD has some pretty crappy "authentication" schemes, such as allowing a cleartext password, and not using HMAC when doing keyed hashes. That's been justified by performance and implementation requirements for BFD. (Not that I ever found those justifications that satisfactory myself:-) I don't think TRILL has the same issues in that (again IIRC) TRILL doesn't define such "dodgy" schemes, so that leads me to wonder if this text is really correct/wise: "...there is little reason to use the [RFC7978] security mechanisms at this time..." I'd have thought that avoiding the more-dodgy BFD mechanisms would be a reason for using TRILL authentication mechanisms. In addition, it's not clear (to me) from the draft if the security assumptions made for BFD still hold in the environments where TRILL is likely to be used. If not, then that'd be another reason to argue that TRILL authentication ought be used.