Subject: Proposed BFD WG

From: Alex Zinin <[email-masked]>
Date: Mon, 22 Mar 2004 15:38:42 -0800

Folks-

 There has been some interest in having a more formal home for the BFD work, so
 we're creating a (hopefully) very focused and short-lived WG for it. Below is
 the proposed WG charter that Daves and I have crafted. Please read and comment.

 Also note that we are looking for the second co-chair. If you would like
 to volunteer and have enough cycles to help, please send me an e-mail.

--
Alex Zinin

Bidirectional Forwarding Detection (BFD)

Current Status: Proposed Working Group

Chairs (tentative):
  David Ward <[email-masked]>
  XXXXX XXXXXX <[email-masked]>

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

Routing Area Advisor:
  Alex Zinin <[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 and submit the specification to the IESG for publication as
    a Proposed Standard.

3. Document BFD encapsulation and usage profile over Ethernet (IEEE 802.3 and
    Ethernet_II) and submit the specification to the IESG for publication as a
    Proposed Standard.

4. Document BFD encapsulation and usage profile for MPLS LSPs and submit
    the specification to the IESG for publication as a Proposed Standard.

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

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

Nov 04    Submit BFD encapsulation and usage profile for Ethernet 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.

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: Rahul Aggarwal <[email-masked]>
Date: Wed, 24 Mar 2004 11:37:22 -0800 (PST)

Hi Alex and WG,

[snip]

>     adjacencies and submit the specification to the IESG for publication as

Should we include BFD over multi-hop IPv4/IPv6 adjacencies (eg. IP/GRE
tunnels) in the charter at this point ?

rahul

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 24 Mar 2004 16:16:37 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rahul Aggarwal
Sent: Wednesday, March 24, 2004 2:37 PM
To: Alex Zinin
Cc: [email-masked]
Subject: BFD WG charter

Hi Alex and WG,

[snip]

	I think we need to be careful because other 
WGs are already taking this on. For example,
PWE3's VCCV already includes a BFD mode over pseudo-wires.
I don't think we want to take that on in the BFD WG.  Similarly
with BFD/MPLS, I think that is something to handle in MPLS. We
might however, want to think about guidance/guidelines for such
activities in other WGs. 

	--Tom

rahul

> draft-katz-ward-bfd-01.txt draft-katz-ward-bfd-v4v6-1hop-00.txt

---

From: [email-masked]
Date: Wed, 24 Mar 2004 23:14:45 +0100

hi thomas, rahul,

Thomas D. Nadeau wrote:
>>  - 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
> 
>>  - Ability to be bootstrapped by any other protocol that
> 
> automatically forms
> 
>>1. Develop the base BFD protocol specification and submit it to the
> 
> IESG
> 
>>2. Document BFD encapsulation and usage profile for single-hop IPv4
> 
> and IPv6
> 
>>    adjacencies and submit the specification to the IESG for
> 
> publication as
> 
>>    a Proposed Standard.
>>
> 
> 

rahul, do you think we have to consider this (1) at the same level, or 
(2) taking into account this aspect while devicing first the single-hop case

> PWE3's VCCV already includes a BFD mode over pseudo-wires.

L3VPN/L2VPN approaches today include BGP and over time the following 
arose (see complete e-mail on the topic (*): "Appropriate level of 
technical review by the protocol-specific WGs needs to be ensured, 
regardless of whether extensions to a given protocol are defined in a 
separate document or not." so i worry a bit about the terms "are already 
taking this on"

(*) 
<https://www1.ietf.org/mail-archive/working-groups/l3vpn/current/msg00404.html>
> might however, want to think about guidance/guidelines for such

and why those guidance/guidelines wouldn't come from the mpls wg to the 
bfd wg in terms of the "oam requirement/framework" umbrella documents 
(for the parts that are applicable in the present context) and that are 
currently ongoing at the mpls wg ?

thanks,
- dimitri.
> 	--Tom
> 
> 
> 
> 
> 
> rahul
> 
> 
> 
>>3. Document BFD encapsulation and usage profile over Ethernet (IEEE
> 
> 802.3 and
> 
>>    Ethernet_II) and submit the specification to the IESG for
> 
> publication as a
> 
>>    Proposed Standard.
>>
>>4. Document BFD encapsulation and usage profile for MPLS LSPs and
> 
> submit
> 
>>5. Develop the MIB module for BFD and submit it to the IESG for
> 
> publication
> 
>>    as a Proposed Standard.
>>
>>
>>Goals and Milestones:
>>
>>Aug 04    Submit the base protocol specification to the IESG to be
> 
> considered
> 
>>           as a Proposed Standard.
>>
>>Nov 04    Submit BFD encapsulation and usage profile for Ethernet to
> 
> the
> 
>>Aug 04    Submit BFD encapsulation and usage profile for MPLS LSPs to
> 
> the
> 
>>Nov 04    Submit BFD MIB to the IESG to be considered as Proposed
> 
> Standard.
> 
>>

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 24 Mar 2004 17:15:39 -0500

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, March 24, 2004 5:15 PM
To: [email-masked]; 'Rahul Aggarwal'
Cc: 'Alex Zinin'; [email-masked]
Subject: Re: BFD WG charter

hi thomas, rahul,

rahul, do you think we have to consider this (1) at the same level, or 
(2) taking into account this aspect while devicing first the single-hop
case

taking this on"

(*) 
<https://www1.ietf.org/mail-archive/working-groups/l3vpn/current/msg0040
4.html>
> I don't think we want to take that on in the BFD WG.  Similarly with 
> BFD/MPLS, I think that is something to handle in MPLS. We might 
> however, want to think about guidance/guidelines for such activities 
> in other WGs.

	That is what I was getting at in terms of "guidance". Guidance 
can be bi-directional. *)

	--Tom

thanks,
- dimitri.

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 24 Mar 2004 14:42:44 -0800 (PST)

Hi Tom,

[snip]

> WGs are already taking this on.

I am not aware of any other WG taking on BFD over IP tunnels.

> For example,

That is for PWs, not PSN IP/GRE tunnels.

rahul

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Mar 2004 08:47:42 +0200 (EET)

> tunnels) in the charter at this point ?

Seems like a more difficult problem to me.  If we are going to do, at 
least work on it after we've finished what else (except maybe the MIB) 
on our plate...

-- 
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: Thu, 25 Mar 2004 11:35:32 -0500

Can't the PSN be IP/GRE tunnels?  I do get
your point, but my point was also that we might
want to try to coordinate this with other WGs
over which BFD is run, instead of doing it here, if 
possible.  Of course, if we cannot find one, then
we should do it here. 

	--Tom

---

From: Alex Zinin <[email-masked]>
Date: Thu, 25 Mar 2004 13:08:53 -0800

Rahul,

> tunnels) in the charter at this point ?

I see two potential cases for multi-hop BFD operations:

 1. IP/GRE tunnels you mention

 2. Multiphop protocol adjacencies (e.g. OSPF VLs, iBGP)

Assuming you mean 1. above, what do you think should be specified given that
tunnels could be considered as logical links from the BFD perspective?
(I'm just trying to understand the scope of related work.)

Thanks.

Alex

---

From: Kaarthik Sivakumar <[email-masked]>
Date: Thu, 25 Mar 2004 16:29:27 -0500

>>> "AZ" == Alex Zinin <[email-masked]> writes:
AZ> I see two potential cases for multi-hop BFD operations:

AZ>  1. IP/GRE tunnels you mention

AZ>  2. Multiphop protocol adjacencies (e.g. OSPF VLs, iBGP)

AZ> Assuming you mean 1. above, what do you think should be specified
AZ> given that tunnels could be considered as logical links from the
AZ> BFD perspective? (I'm just trying to understand the scope of
AZ> related work.)

How about addressing multi-hop BFD operations for iBGP (and eBGP
multihop)? Is there a specific reason why multi-hop for iBGP and OSPF
VLs are not considered? (I am a little late in this game, so I dont
know all the issues yet; just trying a getting a feel for things
here).

kaarthik

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Naiming Shen <[email-masked]>
Date: Thu, 25 Mar 2004 13:44:10 -0800

Alex,

 ] Rahul,
 ] 
 ] > Should we include BFD over multi-hop IPv4/IPv6 adjacencies (eg. IP/GRE
 ] > tunnels) in the charter at this point ?
 ] 
 ] I see two potential cases for multi-hop BFD operations:
 ] 
 ]  1. IP/GRE tunnels you mention
 ] 
 ]  2. Multiphop protocol adjacencies (e.g. OSPF VLs, iBGP)
 ] 

I don't see much benefit to bring protocol multihop adjacencies into
BFD, the tunnels in between can be vulnerable to any routing 
or link problems, to detect the state too fast may not be good. But
if we don't want too fast reaction on those tunnels, protocols themselves
already have 'keepalives' to handle that.

thanks.

 ] Assuming you mean 1. above, what do you think should be specified given that
 ] tunnels could be considered as logical links from the BFD perspective?
 ] (I'm just trying to understand the scope of related work.)
 ] 
 ] Thanks.
 ] 
 ] Alex
 ] 
 ] 

- Naiming

---

From: Dave Katz <[email-masked]>
Date: Thu, 25 Mar 2004 14:10:41 -0800

> know all the issues yet; just trying a getting a feel for things

Aside from the crawl-before-you-walk aspect, the security issue has to 
be dealt with before multihop can be used.

--Dave

---

From: Dave Katz <[email-masked]>
Date: Thu, 25 Mar 2004 14:08:42 -0800

> (I'm just trying to understand the scope of related work.)

Yes, running BFD over tunnels which are realized as virtual interfaces 
falls out of the one-hop draft.  However, there may be further 
specification desired.  For example, the demand mode stuff was put in 
to match the functionality of what was being proposed for IPsec, where 
high fan-in to a single box was apparently felt to be troublesome 
enough to avoid periodic packet transmission.

Of course, you can stand this argument on its head and say that if you 
have very high real (or more likely channelized) interface counts, you 
may want to use demand mode anyhow.

All this dances around how one should specify the applications of BFD, 
and I'm not too clear on the best way to do that.

--Dave

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 25 Mar 2004 14:15:15 -0800 (PST)

Hi Alex,

> (I'm just trying to understand the scope of related work.)

I was implying 1. And as you mention from a BFD perspective most of the
details are same as the single hop IP case and the single hop IP
draft will cover most of it. Tunnel encap will
be used: (IP or IP + GRE or IP + IPSec) to encapsulate BFD packets.
Bootstrapping will be based on tunnel configuration or maybe discovering a tunnel
endpoint: very much application specific. So the scope of the work is
probably quite small. I wanted to ensure that it alligns with the charter now or
at some point in the future.

The only thing that may require looking at further is BFD for IPsec...

Thanks,
rahul