Tom, I hear you. The BFD chairs are working with me on this and we expect (well I demand ;-) to have new milestones out within 7 days. Adrian > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of t.p. > Sent: 08 November 2012 14:56 > To: afarrel@xxxxxxxxxxx; ietf@xxxxxxxx > Subject: Re: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) > > ----- 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