Re: [OSPF] BFD re-charter complete

[Manav Bhatia <[e-mail]>]

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" <[e-mail]> 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 <[e-mail]> -----
>
> Date: Thu, 05 Jun 2014 10:16:58 -0700
> From: The IESG <[e-mail]>
> To: IETF-Announce <[e-mail]>
> Cc: bfd WG <[e-mail]>
> 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 <[e-mail]>
>   Jeffrey Haas <[e-mail]>
>
> Technical advisors:
>   Dave Katz <[e-mail]>
>   David Ward <[e-mail]>
>
> Assigned Area Director:
>   Adrian Farrel <[e-mail]>
>
> Mailing list
>   Address: [e-mail]
>   To Subscribe: [e-mail]
>   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 -----
>
>