Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support
draft-ietf-trill-rbridge-bfd-07

Thanks for working on the Discuss points and my Comments. The new revision has resolved most of them and I am downgrading the remaing two Discuss points to be Comments. I still hope they will be looked at, but I do not think they merit blocking the document.

---

In looking for a a reference to be added to draft-ietf-trill-rbridge-oam
(and/or to draft-ietf-trill-oam-req or draft-salam-trill-oam-framework)
I am seeking joined-up thinking about OAM within Trill such that the
reader can see that BFD is just part of the overall OAM solution and
can understand when other tools might be more appropriate. 
Although the document is self-contained wrt motivation for BFD, it
does not present the necessary hooks for seeing the whole OAM 
picture.

In general, one would expect the OAM requirements and framework 
to be developed first, and solutions to follow. But I understand that
carts often get ahead of horses. Thus normative references might not
be an absolute requirement. But some form of reference is really
desirable.

---

> Finally, although I understand that the scope of this document is
> limited to encapsulation, I think that this leaves the solution
> deficient. It needs a description of bootstrapping in the Trill
> environment.

The authors proposed adding text to section 2.1 to say:

  For many applications, a means of triggering or bootstrapping the BFD
   session is required. This will be specified with the particular use of
   BFD over TRILL. For example, see draft-hpothetical-trill-rfc6327bis.

This would be good.

Minor comments; no need to respond:
I find citing nroff in the Acknowledgments section to be odd, for whatever that's worth.  (I also can't remember when I last saw an actual normative reference to ASCII.)

Thank you for addressing my DISCUSS so quickly.

Thank you for addressing my discuss.

I agree with the shepherd's recommendation to change the reference for [ASCII] to ANSI X3.4. I suggest looking at the references in RFC5891 for an example:

[ASCII]      American National Standards Institute (formerly United
                States of America Standards Institute), "USA Code for
                Information Interchange", ANSI X3.4-1968, 1968.  ANSI
                X3.4-1968 has been replaced by newer versions with
                slight modifications, but the 1968 version remains
                definitive for the Internet.

- I'm not clear if the key derivations described in section
6 are mandatory to implement or not. It says that if IS-IS
auth is in effect, then you "use" (would that be better with
a 2119 MUST?) BDF Meticulous Keyed SHA1 (nice name btw:-),
but its not clear to me if that means this is MTI or not.

- What does "that state of IS-IS shared secret" mean?  Maybe
s/that state//?

- I don't get why this only needs/uses key ID 0, can you
explain further? I guess I'd have expected that if the
IS-IS-shared-key had a key ID, then that would be used for
the derived key(s) defined here.

- I'm wondering if the authentication scheme described here
is really used or not? I think it'd be good to say if its
real or fictional, if that is known.

Thank you for addressing my concerns with this document.