Last Call Review of draft-ietf-trill-p2mp-bfd-07
review-ietf-trill-p2mp-bfd-07-secdir-lc-farrell-2017-12-28-00

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.