Last Modified: 2004-06-17
BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods.
Important characteristics of BFD include:
- Simple, fixed-field encoding to facilitate implementations in hardware
- Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network.
- Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course.)
- Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery.
At this time the WG is chartered to complete the following work items (additional items will require rechartering):
1. Develop the base BFD protocol specification and submit it to the IESG for publication as a Proposed Standard 2. Document BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies (e.g, physical links and IP/GRE tunnels for static routes, IS-IS, OSPFv2, OSPFv3, single-hop BGP) and submit the specification to the IESG for publication as a Proposed Standard. 3. Document BFD encapsulation and usage profile for MPLS LSPs and submit the specification to the IESG for publication as a Proposed Standard. 4. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 5. Document BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies (e.g. OSPF virtual links and iBGP sessions) and submit the specification to the IESG for publication as a Proposed Standard.
Topics for Possible Future Work:
1. Document BFD directly over 802.3 in close collaboration and synchronization with the IEEE.
| 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
IETF-60 Presenters: Dave Ward: o Agenda o Base specification o single hop ipv4, ipv6 o multihop BFD Rahul Aggarwal: o BFD for MPLS LSPs Tom Nadeau: o BFD MIB Dave Allan: o BFD extensions for PW Exchanges of Fault Notifications. Jeff Haas: o Standards Process Dave Ward: Agenda bashing - no changes. Agenda overview: --------------- Reviews of base specification changes, also single-hop ipv4, ipv6 Bootstrap BFD for LSPs MIB - Tom Nadeau Appliciations draft for L2-VPN O&M from David Allan. This document depends on whether L2 VPN WG decides to take this on this work Changes being requested to BFD Whether or not the current diagnostic codes are sufficient. Dave Ward: Deltas of base spec ------------------------------- Extensions to the base specification: C - control plane independant bit. One reviewer of draft noted that we didn't have control plane independence in the router. This would be the only signal of whether we were non-stop-forwarding capable. A - authentication bit. Everything else is largely the same. Overview of authentication: Optional header extention for authentication. Generic form of header Different types of authentication: o Simple password o Keyed MD5 Plenty of bits for future use Simple password authentication very similar to other protocols. MD5 variants, also very similar to other protocols. Variant 1: Increment sequence number in header periodically - does not have to increment each time. Variant 2: Meticulous md5 - increments the sequence number every single time. Multiple keys The draft recommends GTSM You SHOULD use authentication whenever you do multi-hop BFD, but clearly you're free to use it any time you like. Other changes: Local discriminator allowed to change any time for a session. It was decided to do this because specification used to require you to note do it, but there was not a good reason. This also removes the requirement to clear remote discriminator whenever the session goes down. Zafar: Concerns that we were rapidly using up the bits in the BFD header. Dave Katz: We can reserve one bit to say that there will be an extension that provides further bits. "You reserve the last coding point as a way of buying yourself further coding points." Single hop specification -------------------------- Very few changes. Clarification of BFD over OSPF virtual links - basically follow what we're suggesting for multihop sessions. When tunneling, don't decrement the TTL hop count [Section 8] Also when tunneling, use the authentication mechanisms. Multi hop specification ------------------------ Needed more work. Issues incnluded: How do we de-multiplex the first packet exchanged when the discriminator values were not exchanged? What about security? Spoofing? Authentication? De-multiplexing: We don't know what "your discriminator value is going to be". On single-hop, you can use the interface to de-multiplex the values. You can't do this in multi-hop since multiple sessions may be served by a single interface. A couple solutions: 1. Use arbitrary paths with different source:destination pairs 2. Out of band discriminator signaling like BFD for MPLS where we will never have a your discriminator value of zero. Unidirectional link - either solution works. You can also use some active/passive tricks where the sender plays the active role and the receiver plays the passive role. When in passive role, you only send out packets after you receive packets. The receiver is the demultiplexor at that point. Further comments: We'd like to extend the comments for 30 more days and then ask the working group chairs to put out a working group last call for proposed standard. There are 3 independant implementations. Please tell us if you have one so we can add it to the implementation report. Question: Multiple sessions on a single entity - how do we associate them for a different appliciations? Dave Katz: Implementation specific. Two entities are typically expected to happen for only one session between two entities. If you have multiple protocols running between these two entities, the single BFD session should signal all of the protocols. However, nothing stops you from doing whatever you want. We're trying hard to not specify things that do not affect interoperability. Question: What about different paths? Dave Katz: The BFD session is very distinct from it's application. You could have a BFD session where one side is using it to trigger OSPF and the other one isn't. We're trying to keep the links between the application's use of BFD and the session very minimal. In impliciations he's seen he hasn't seen it necessary for the application to know that they're using BFD. When it is, this should be communicated within the protocol. Dave Ward: We're also trying to not make this an RP or protocol liveness protocol. That's where we originally started, but we've gone beyond this. We want to try to keep details about what protocol even set up the session out of this. Question: Is there anything in the spec about an implementation of trigger between a BFD state change and the appliciation? DK: There is a MAY or a SHOULD. It's nominally required that when the BFD session fails, "you should tell someone". Also, if the BFD session doesn't come up, you MUST NOT hold your OSPF session down because of it. You probably should signal a trigger when the session goes down and everything else is outside the scope of the specification. Question: Is there some context or a session ID that indicates an association to a trigger for a session? Dave Katz: That's internal to your implemenation. If it isn't signaled in the protocol, it doesn't belong in the specification. BFD for MPLS LSPs. -------------------- [Note that much of the session didn't get recorded clearly due to some microphone problem. However, the comments were brief.] Rahul Aggarwal: We are requesting this to be made a BFD WG document. It has components that are currently in the MPLS working group. A comparison between BFD and LSP-PING was given and the expected appliciability of each mechanism. LSP-PING has greater operational overhead. BFD is much lighter weight and is more appropriate as a liveness mechanism. Discussion about using out of band mechanism to bootstrap BFD session from the Internet-Draft. Dave Ward: We would like to bring this into the WG as a WG document as long as LSP-PING is adopted as a WG item. Per George (MPLS WG chair), we were going to take this bootstrapping of BFD into the WG. George: Doesn't really care where the work gets done so long as it gets done. BFD MIB. ---------- Tom Nadeau Changes from previous versions of document. Need to update the MIB to reflect the current protocol structure General makeup of MIB: o Configured sessions o Session state will capture all sessions on the box regardless of who owns the session. o Performance table that contains performance stats for each session o Session mapping table. Session and performance table indexed by simple key only significant to the router - because we can have 10's of thousands of bfd sessions. The mapping table lets you map from session id to the true keys. o Only a few scalar variables Session table: Shows session from the box - flat indexing scheme. Question to the working group: Is the structure of this sufficient for the operators that want to use this? We (Zafar and Tom) really need to know. Session performance table: Number of sessions, up and down sessions, etc. It is important for operators to look at this! The current functionality is extrapolated from the drafts. 2 notifications - session up and down. They can be grouped together so that you can do one notification in place of X contiguous ones. One more revision needs to be made to bring it up for the last call - waiting on next version of base draft. Question to the WG Chairs: Do we have a MIB doctor? Chairs: No. We need one assigned. Tom: Would like one to look this right away. BFD extensions for PW Exchanges of Fault Notifications. -------------------------------------------------------- David Allan: Anyone not at l2vpn? The slides were edited somewhat from that session. BFD extension related to pseudowires. Vasile is coauthor. Motiviation: BFD diagnostic codes and procedures need to be extended to cover psuedowire operational scenarios. BFD seems to be a good fit for this. New diagnostic codes suggested - slightly different semantics than existing codes. Discussion points: This is close to the LDP status tlv? The two additional BFD diagnostic codes requested may be sufficient. Do the diagnostic codes need the sense of direction? We think so. Overlap of functionality with AIS(?) notification. Discussion of pseudowire components. Noted how when the BFD session is signalled when the attachment circuit goes down there is a loss of some AC diagnostic information since the existing diagnostic codes can't convey quite the right signaling information. There was some spirited discussion as to why particular BFD diagnostics were converted to particular AC circuit down signaling. The AIS protocol apparently has enough richness to convey this information, but BFD does not. Dave Katz: More generic names for these events would make the diagnostic codes more palatable. Dave Ward: If the l2vpn group accepts this mechanism, we can adopt this mechanism within BFD. There was a lot of general discussion over the appropriateness of BFD to convey the OAM information for the pseudowire. DK/DW: Not in opposition to making appropriate changes, but need to get some consensus as to what is "appropriate". >From someone in the WG: Is LSP-Ping more appropriate? Dave Allan: Yes, but it's not light weight enough. Dave Katz: We're trying to keep this a generic mechanism and adding some PWE3 specific components goes against the spirit of that. Jeff Haas: It looks like this is good for PE-PE, but may not be appropriate for the other components? Dave Allan: There are number of scenarios we're trying to work through. Standards Process. ------------------- Jeff Haas: IESG asked for clarification on our security practices. MD5 may not sufficient. They are getting clarification. It was suggested that SHA-1 should be added as a SHOULD. We have a depenency on the MPLS WG for LSP-PING. LSP-PING and BFD for MPLS LSPs will have to advance together in the standards track. The BFD documents require the new boilerplate and will need to follow the new ID-checklist. IPR disclosures are requirerd. The co-authors of the base specification have been asked for this. Dave Ward to Bill Fenner: SHA-1 - are we still getting this issue cleared up? Bill Fenner: The security guys say we just need replay protection. Dave Ward: If you want me to put SHA-1 in here, we'll do it. Bill Fenner: SHA-1 isn't an issue. Keying and replay is an issue. Jeff Haas: Per bar conversation with Steve, we just need to add some extra entropy to the keyspace. As Tom mentioned, we'll need to make some changes ot the MIB. We need one implementation, we have 3. We need further community or cross area review. We have other things to take to other WGs for their or adoption as a working group item before we can adopt the other items. E.g. L2VPN O&M. We need IANA considerations for items like code points for error codes. We are hoping to have WG last call well before November IETF session. |