I realise that the timekeeping of the IETF is not on a par with its engineering, but it seems a shame to promulgate a new charter for which every milestone is already several months in arrears. Tom Petch ----- Original Message ----- From: "The IESG" <iesg-secretary@xxxxxxxx> To: "IETF-Announce" <ietf-announce@xxxxxxxx> Cc: "bfd WG" <rtg-bfd@xxxxxxxx> Sent: Tuesday, October 30, 2012 3:46 PM > The Bidirectional Forwarding Detection (bfd) working group in the Routing > Area of the IETF has been rechartered. For additional information please > contact the Area Directors or the WG Chairs. > > Bidirectional Forwarding Detection (bfd) > ------------------------------------------------ > Current Status: Active Working Group > > Chairs: > David Ward <dward@xxxxxxxxx> > Jeffrey Haas <jhaas@xxxxxxxx> > > Technical advisors: > Dave Katz <dkatz@xxxxxxxxxxx> > > Assigned Area Director: > Adrian Farrel <adrian@xxxxxxxxxxxx> > > Mailing list > Address: rtg-bfd@xxxxxxxx > To Subscribe: rtg-bfd-request@xxxxxxxx > Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ > > Charter of Working Group: > > The BFD Working Group is chartered to standardize and support the > bidirectional forwarding detection protocol (BFD) and its extensions. A > core goal of the working group is to standardize BFD in the context of IP > routing, or protocols such as MPLS that are based on IP routing, in a way > that will encourage multiple, inter-operable vendor implementations. The > Working Group will also provide advice and guidance on BFD to other > working groups or standards bodies as requested. > > 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. > > The working group is chartered to complete the following work items: > > 1. Develop the MIB module for BFD and submit it to the IESG for > publication as a Proposed Standard. > > 2a. Provide a generic keying-based cryptographic authentication mechanism > for the BFD protocol in discussion with the KARP working group. This > mechanism will support authentication through a key identifier for the BFD > session's Security Association rather than specifying new authentication > extensions. > > 2b. Provide extensions to the BFD MIB in support of the generic > keying-based cryptographic authentication mechanism. > > 2c. Specify cryptographic authentication procedures for the BFD protocol > using HMAC-SHA-256 (possibly truncated to a smaller integrity check > value) using the generic keying-based cryptographic authentication mechanism. > > 3. Provide an extension to the BFD core protocol in support of point-to- > multipoint links and networks. > > 4. Assist the MPLS working group in the standardization of the BFD > protocol for MPLS-TP. The preferred solution will be interoperable with the > current BFD specification. > > 5. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. > > The working group will maintain a relationship with the KARP and MPLS > working groups, and will communicate with the IEEE with respect to BFD > over LAGs. > > Milestones: > Done - Submit the base protocol specification to the IESG to be > considered as a Proposed Standard > Done - Submit BFD encapsulation and usage profile for single-hop > IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed > Standard > Done - Submit BFD encapsulation and usage profile for MPLS LSPs to > the IESG to be considered as a Proposed Standard > Done - Submit BFD encapsulation and usage profile for multi-hop > IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed > Standard > Sep 2011 - Submit the BFD MIB to the IESG to be considered as a > Proposed Standard > Dec 2011 - Submit the generic keying based cryptographic authentication > mechanism to the IESG to be considered as a Proposed Standard > Dec 2011 - Submit a BFD MIB extension in support of the generic keying > document to the IESG to be considered as a Proposed Standard > Dec 2011 - Submit the cryptographic authentication procedures for BFD > to the IESG to be considered as a Proposed Standard > Mar 2012 - Submit the the document on BFD point-to-multipoint support > to the IESG to be considered as a Proposed Standard > Jun 2012 - Submit the bootstrapping mechanism for BFD using DHCP to the > IESG to be considered as a Proposed Standard >