----- Original Message ----- From: "Adrian Farrel" <afarrel@xxxxxxxxxxx> To: "'t.p.'" <daedulus@xxxxxxxxxxxxx>; <ietf@xxxxxxxx> Sent: Sunday, November 04, 2012 5:43 PM > Hello Tom. > > Charter text is distinct from milestones. > The charter is discussed by IESG and put out for community review. > Milestones are set by the chairs in discussion with their AD. > The process for handling the updates is also different. > > The BFD chairs agreed with me that they would update the milestones once the new > charter text was posted, so I hope we'll see that "soon". Understood, but be aware of the impact it has, at least on me. I was glad to see that one item, which I expect to engage with, was still in the Charter and then looked below to see when I might want to set aside time for it, only to see all those dates in the past, reminiscent of all those failed project plans that I have seen over the years. If the dates are not updated, then I would think it a better process to send out just the updated Charter, without any dates. Tom Petch > Cheers, > Adrian > > > -----Original Message----- > > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of t.p. > > Sent: 01 November 2012 09:28 > > To: ietf@xxxxxxxx > > Subject: Re: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) > > > > 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