Subject: BFD charter rev 2

From: Alex Zinin <[email-masked]>
Date: Tue, 20 Apr 2004 12:05:38 -0700

Folks-

 Rev 2 of the charter is below. The html-diff is available at:
 http://www.psg.com/~zinin/ietf/bfd-charter-00-01-diff.html

 Please send your comments by April 27, 2004.
-- 
Alex

Bidirectional Forwarding Detection (BFD)

Current Status: Proposed Working Group

Chairs (tentative):
  David Ward <[email-masked]>
  Jeff Haas <[email-masked]>

Routing Area Directors:
  Bill Fenner <[email-masked]>
  Alex Zinin <[email-masked]>

Routing Area Advisor:
  Alex Zinin <[email-masked]>

Technical Advisor:
  Dave Katz <[email-masked]>

Mailing Lists:

  General Discussion: [email-masked]
  Send mail to: [email-masked]
  With a subject line: subscribe
  Archive: ftp://ftp.ietf.org/ietf-mail-archive/rtg-bfd-wg

Description of Working Group:

The BFD Working Group is chartered to specify a protocol for bidirectional
forwarding detection (BFD), as well as extensions to be used within the scope of
BFD and IP routing, in a way that will encourage multiple, inter-operable vendor
implementations.

BFD is a protocol intended to detect faults in the bidirectional path between
two forwarding engines, including interfaces, 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.

At this time the WG is chartered to complete the following work items
(additional items will require rechartering):

  1. Develop the base BFD protocol specification and submit it to the IESG     
     for publication as a Proposed Standard                                    
                                                                               
  2. Document BFD encapsulation and usage profile for single-hop IPv4 and IPv6 
     adjacencies (e.g, physical links and IP/GRE tunnels for static routes,    
     IS-IS, OSPFv2, OSPFv3, single-hop BGP) and submit the specification to the
     IESG for publication as a Proposed Standard.                              
                                                                               
  3. Document BFD encapsulation and usage profile for MPLS LSPs and submit     
     the specification to the IESG for publication as a Proposed Standard.     
                                                                               
  4. Develop the MIB module for BFD and submit it to the IESG for publication  
     as a Proposed Standard.                                                   
                                                                               
  5. Document BFD encapsulation and usage profile for multi-hop IPv4 and IPv6  
     adjacencies (e.g. OSPF virtual links and iBGP sessiosn) and submit        
     the specification to the IESG for publication as a Proposed Standard.     

Topics for Possible Future Work:

  1. Document BFD directly over 802.3

Goals and Milestones:

Aug 04    Submit the base protocol specification to the IESG to be considered
          as a Proposed Standard.

Aug 04    Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6
          adjacencies to the IESG to be considered as a Proposed Standard

Aug 04    Submit BFD encapsulation and usage profile for MPLS LSPs to the
          IESG to be considered as a Proposed Standard

Nov 04    Submit BFD MIB to the IESG to be considered as Proposed Standard.

Feb 05    Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6
          adjacencies to the IESG to be considered as a Proposed Standard

Internet-Drafts (to be WG items):

draft-katz-ward-bfd-01.txt
draft-katz-ward-bfd-v4v6-1hop-00.txt
draft-raggarwa-mpls-bfd-00.txt
draft-nadeau-bfd-mib-00.txt

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Apr 2004 08:11:32 +0300 (EEST)

>  Please send your comments by April 27, 2004.

I'd restrict the scope of the initial charter more, i.e., move action 
item 5 under "Topics for Possible Future Work".

It's more important to finish the "easy" cases first.

It might also be appropriate to consider Experimental for multihop 
usage profile, as I'm guessing that it has a number of issues with 
security, but PS is fine as well.  I'd just prefer that we'd 
consciously postpone that until we are done with the critical and 
relatively easy work.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: 22 Apr 2004 12:01:18 -0400

A few points:

1)

	I would change the following

The BFD Working Group is chartered to specify a protocol for
bidirectional forwarding detection (BFD), as well as extensions to be
used within the scope of BFD and IP routing, in a way that will
encourage multiple, inter-operable vendor implementations.

	to the following because later in the charter you
explicitly spell out MPLS.

The BFD Working Group is chartered to specify a protocol for
bidirectional forwarding detection (BFD), as well as extensions to be
used within the scope of BFD, IP routing, or protocols
such as MPLS that are based on IP routing.

2) 

	I would change the following:

BFD is a protocol intended to detect faults in the bidirectional path
between
two forwarding engines, including interfaces, data link(s), and to the
extent
possible the forwarding engines themselves, with potentially very low
latency.

	To:

BFD is a protocol intended to detect faults in the bidirectional path
or paths between two forwarding engines, including physical interfaces, 
sub-interfaces, data link(s), and to the extent possible, the forwarding
engines themselves, with potentially very low latency and low resource
overhead.

3)

	I am concerned over the following statement, 

	"It operates independently of media, data protocols, and routing
protocols."

	 given that the first part of the charter explains that it be used
within the scope of BGP/IP routing only, 

	"The BFD Working Group is chartered to specify a protocol for
bidirectional forwarding detection (BFD), as well as extensions to be
used within the scope of BFD and IP routing, in a way that will
encourage multiple, inter-operable vendor implementations."  

	Similarly, the following seems to contradict the scoping statement as
well, 

	"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."

	It would seem better to either widen the scoping restriction
or to narrow the Topics for Possible Future Work:

  1. Document BFD directly over 802.3scope of the paragraphs pointed out
above.

4) 
	I have a question about the following:

	4. Develop the MIB module for BFD and submit it to the IESG for
publication as a Proposed Standard. 

	Does the WG and AD's care whether this MIB contains
configuration, statistics and is capable of read-write operation?
In particular, theTopics for Possible Future Work:

  1. Document BFD directly over 802.3 read-write portion can
significantly 
complicate matters.

5) 

	I would modify the following:

	To:

  1. Document BFD directly over 802.3 in close collaboration
	and synchronization with the IEEE.

	--Tom

---

From: Dave Katz <[email-masked]>
Date: Thu, 22 Apr 2004 15:58:28 -0700

> It's more important to finish the "easy" cases first.

Multihop will be required for MPLS (since the return path may not be an 
LSP, and perhaps arguably should not be) so other multihop applications 
would more or less fall out of that for free.  Security is required for 
multihop, so that pretty much means that the whole ball of wax has to 
be done for MPLS.

This is the meat of the technical work remaining to be done, in any 
case.

--Dave

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 22 Apr 2004 23:03:47 -0400

> This is the meat of the technical work remaining to be done, in any 

Plus, having this work item projected for Feb 2005 gives us time to
work on the "easy" parts first.  Presumably this would satisfy most
of Pekka's concern of not unnecessarily distracting the WG from the
parts that can come quicker.

[Pekka]
> > consciously postpone that until we are done with the critical and

Security is probably the most complicated piece here and potentially
is a issue for the non-multihop case as well, even with GTSM-like
behavior.

There's also the issue about choosing appropriate times such that
BFD interacts appropriately with the underlying IGP/signalling  protocols.
This problem also needs solved for LSPs.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 22 Apr 2004 23:56:09 -0400

All in my personal opinion:

> 	I would change the following
[...]

> such as MPLS that are based on IP routing.

This seems reasonable.

> engines themselves, with potentially very low latency and low resource

While sub-interfaces makes some sense to call out, do we really wish to 
add "paths" here?  While I can easily see the desire to verify
bidirectional reachability of each path I can also see it being an
issue that creates a lot of additional complexity.

> encourage multiple, inter-operable vendor implementations."  

I believe the key words in the above paragraph are "as well as", which
implies to me that "we're specifying the BFD protocol PLUS extensions".

Any suggestions on how to tidy this up a bit?

> configuration, statistics and is capable of read-write operation?

I'm also interested in the general opinion given my work on the BGP MIBs
and the otherwise resounding silence on such matters. :-)

> 	and synchronization with the IEEE.

Complete with triple-secret handshake. :-)

-- 
Jeff Haas 
NextHop Technologies