Hi Jeff, What about the ospf/isis extn drafts for distributing the sbfd discriminators? I guess these would be owned by the respective IGP WGs. Is this correct?
Cheers, Manav -- Thumb typed by Manav On Jun 10, 2014 7:23 PM, "Jeffrey Haas" <[email protected]> wrote: > Working Group, > > Our updated charter was approved by the IESG. The S-BFD work is officially > in scope now! > > Per our prior discussion, authors please submit the following documents as > draft-ietf-bfd-*: > > draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) > draft-akiya-bfd-seamless-base (Milestone: March 2015) > > The following documents are known to be work of interest, but aren't quite > ready for adoption. Please kick off additional discussions to drive that > work forward: > > draft-akiya-bfd-seamless-ip > draft-akiya-bfd-seamless-sr > draft-akiya-bfd-seamless-alert-discrim > > My recommendation is to drive the IP case first. > > -- Jeff > > > > > > ----- Forwarded message from The IESG <[email protected]> ----- > > Date: Thu, 05 Jun 2014 10:16:58 -0700 > From: The IESG <[email protected]> > To: IETF-Announce <[email protected]> > Cc: bfd WG <[email protected]> > Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) > > 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 WG > > Chairs: > Nobo Akiya <[email protected]> > Jeffrey Haas <[email protected]> > > Technical advisors: > Dave Katz <[email protected]> > David Ward <[email protected]> > > Assigned Area Director: > Adrian Farrel <[email protected]> > > Mailing list > Address: [email protected] > To Subscribe: [email protected] > Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ > > Charter: > > 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 currently chartered to complete the following work > items: > > 1. Develop further MIB modules for BFD and submit them to the IESG for > publication as Proposed Standards. > > 2a. Provide a generic keying-based cryptographic authentication > mechanism for the BFD protocol developing the work of 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 but not beyond commonly accepted lengths to ensure security) 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. Provide an informational document to recommend standardized timers > and timer operations for BFD when used in different applications. > > 5. Define a mechanism to perform single-ended path (i.e. continuity) > verification based on the BFD specification. Allow such a mechanism to > work both proactively and on-demand, without prominent initial delay. > Allow the mechanism to maintain multiple sessions to a target entity and > between the same pair of network entities. In doing this work, the WG > will work closely with at least the following other WGs: ISIS, OSPF, > SPRING. > > The working group will maintain a relationship with the MPLS working > group. > > 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 > Done - Submit the BFD MIB to the IESG to be considered as a > Proposed Standard > Done - Submit the BFD over LAG mechanism to the IESG to be > considered as a Proposed Standard > Jun 2014 - Submit the the document on BFD point-to-multipoint support > to the IESG to be considered as a Proposed Standard > Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be > considered as a Proposed Standard > Jan 2015 - Submit the generic keying based cryptographic authentication > mechanism to the IESG to be considered as a Proposed Standard > Jan 2015 - Submit a BFD MIB extension in support of the generic keying > document to the IESG to be considered as a Proposed Standard > Jan 2015 - Submit the cryptographic authentication procedures for BFD > to the IESG to be considered as a Proposed Standard > Jan 2015 - Submit the BFD Common Intervals document to the IESG to be > considered as an Informational RFC > > > ----- End forwarded message ----- > >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
