Last Modified: 2005-02-09
Aug 04 | Submit the base protocol specification to the IESG to be considered as a Proposed Standard. | |
Aug 04 | Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard | |
Aug 04 | Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard | |
Nov 04 | Submit BFD MIB to the IESG to be considered as Proposed Standard. | |
Feb 05 | Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard |
BFD Working Group minutes
IETF 62 Chairs: Dave Ward, Jeff Haas Updates on the specifications, Dave Ward ------ A new state machine has been added. Added support for SHA-1 authentication Added text clarifying what IGPs should do during a Graceful Restart Responded and incorporated all comments and inquiries on the base list Generic bootstrap document will be written and should become a working group draft. Added 2 diagnostic codes dealing with concatenated path down. Note that bfd session isn't taken down in this case. Security changes: Added support for SHA-1. Removed requirement to drop session when changing authentication. Introduced incompatible state machine change, we're now BFD version 1. Protocol now carries the state that the remote state machine is in. The protocol no longer has an "I hear you" bit. [Discussion about potential protocol expansion issues. Answer, we still have a reserved bit.] Version 1 will become the default version of the protocol Version 0 is not widely deployed, so this shouldn't be an issue. BFD IS-IS interaction For details, see IS-IS WG New drafts will be out shortly after IETF Review period of 3 weeks on the draft. WG last call 3 weeks after that. Discussion: Pekka: TTL 255 removed? Dave W: When running authentication, don't need to verify TTL Pekka: We want to do the TTL check first to protect against attacks on the authentication system. Dave W: It can be configured on. Pekka: It should say it must be configured. Dave K: If your implementation can't handle bad authentication packets [at line rate], your implementation [has problems]. Pekka: [Concern about authentication to be used as an attack on the control plane] Dave W: You can still configure the TTL 255 check Pekka: If you're running without authentication, you *must* use the TTL check Jeff: Show of hands in the room, should we require the TTL check when using authentication [yes] Dave K: There are known situations when the TTL check is known broken. E.g. the implementation decrements the TTL internally. Jeff: There appears to be some consensus that the TTL should be a SHOULD, instead of a MAY; not a must. [?] - Default Configuration parameters as part of the spec? Dave K: Configuration parameters don't belong in the spec Dave W: [?] Dave K: SHOULD works for me Working group procedural status, Jeff ----- We're late on our deliverables. The WG was reminded of our charter to create a protocol to detect forwarding plane liveness. This is a very tightly focused WG meant to address a generic solution on a number of media. Solutions for specific problems on given media are likely out of scope. |