From rtg-bfd-bounces@ietf.org Sun Oct 09 13:22:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOesX-0003HH-1H; Sun, 09 Oct 2005 13:22:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOesV-0003GM-Jd for rtg-bfd@megatron.ietf.org; Sun, 09 Oct 2005 13:22:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28396 for ; Sun, 9 Oct 2005 13:22:24 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOf2E-0000t7-Kp for rtg-bfd@ietf.org; Sun, 09 Oct 2005 13:32:31 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2005 19:22:17 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j99HMFOk003136; Sun, 9 Oct 2005 19:22:15 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 9 Oct 2005 19:22:14 +0200 Received: from [192.168.50.240] ([10.61.80.74]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 9 Oct 2005 19:22:14 +0200 User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Sun, 09 Oct 2005 12:22:24 -0500 From: David Ward To: BFD , David Ward , Jeffrey Haas Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Oct 2005 17:22:14.0528 (UTC) FILETIME=[FDB1F800:01C5CCF5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit Cc: Subject: BFD WG request for agenda slots at IETF 64 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org It's that season again. Please let us know if you would like an agenda slot at IETF 64 in Vancouver. From rtg-bfd-bounces@ietf.org Mon Oct 24 15:51:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Li-0003Mv-6u; Mon, 24 Oct 2005 15:51:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Kd-0002uB-DL; Mon, 24 Oct 2005 15:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28595; Mon, 24 Oct 2005 15:49:52 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8XO-0007cj-3X; Mon, 24 Oct 2005 16:03:19 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EU8KY-0002Ht-M5; Mon, 24 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-base-04.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Bidirectional Forwarding Detection Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-base-04.txt Pages : 44 Date : 2005-10-24 This document describes 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. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-base-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-base-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-24151229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-base-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-base-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-24151229.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Mon Oct 24 15:51:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Lt-0003Qh-C6; Mon, 24 Oct 2005 15:51:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Kd-0002uC-Rt; Mon, 24 Oct 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28605; Mon, 24 Oct 2005 15:49:53 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8XO-0007ci-57; Mon, 24 Oct 2005 16:03:19 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EU8KY-0002HQ-L2; Mon, 24 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-04.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for IPv4 and IPv6 (Single Hop) Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-v4v6-1hop-04.txt Pages : 12 Date : 2005-10-24 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. It further describes the use of BFD with OSPFv2, OSPFv3, and IS-IS. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-v4v6-1hop-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-24150959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-24150959.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Mon Oct 24 18:50:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB98-0004j9-7t; Mon, 24 Oct 2005 18:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB8l-0004cE-PY; Mon, 24 Oct 2005 18:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26546; Mon, 24 Oct 2005 18:49:50 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUBLa-0002qc-UM; Mon, 24 Oct 2005 19:03:19 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUB8j-0007C5-SN; Mon, 24 Oct 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Oct 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-generic-01.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Generic Application of BFD Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-generic-01.txt Pages : 9 Date : 2005-10-24 This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol in environments not specifically documented in other specifications. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-generic-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-generic-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-24162511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-generic-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-generic-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-24162511.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Tue Oct 25 01:16:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUHB2-0007AP-Ay; Tue, 25 Oct 2005 01:16:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUHB0-0007AG-1o for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 01:16:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20590 for ; Tue, 25 Oct 2005 01:16:32 -0400 (EDT) From: kalpana.yenishetti@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUHNn-00062X-3q for rtg-bfd@ietf.org; Tue, 25 Oct 2005 01:30:05 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 94204205E1 for ; Tue, 25 Oct 2005 10:34:02 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 75AAF20519 for ; Tue, 25 Oct 2005 10:34:02 +0530 (IST) Received: from hyd-mdp-msg02.wipro.com ([10.150.49.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 10:46:24 +0530 Received: from HYD-MKD-MBX01.wipro.com ([10.154.50.182]) by hyd-mdp-msg02.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 10:46:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D922.F1CA7560" Date: Tue, 25 Oct 2005 10:44:15 +0530 Message-ID: Thread-Topic: BFD queries Thread-Index: AcXZI+ej2ZcNkaY9Qd6sEr3B02YDrw== To: X-OriginalArrivalTime: 25 Oct 2005 05:16:27.0042 (UTC) FILETIME=[3FFAF020:01C5D923] X-Spam-Score: 0.4 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Subject: BFD queries X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D922.F1CA7560 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi=20 =20 I have following query from the BFD draft=20 =20 1. When a BFD session is established between two nodes in a network, and if one of the system sends a BFD control packet with POLL bit set to change any the Min Tx/Rx intervals and the receives response to the previous BFD packet. This could lead to situation where sender assuming his request for configuration change for Min Tx/Rx intervals is declined.=20 2. If the choosen transport protocol for BFD transmission is UDP, the FIN bit set packet is lost then there will be discrepancy the configuration between the configured nodes.=20 =20 =20 Thanks & Regards -Kalpana =20 ------_=_NextPart_001_01C5D922.F1CA7560 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi

 

I have following query from the BFD draft =

 

  1. When a BFD session is established between two nodes in a network, and if one of the = system sends a BFD control packet with POLL bit set to change any the Min Tx/Rx = intervals and the receives response to the previous BFD packet. This could = lead to situation where sender assuming his request for configuration = change for Min Tx/Rx intervals is declined.
  2. If the choosen = transport protocol for BFD transmission is UDP, the FIN bit set packet is = lost then there will be discrepancy the configuration between the configured = nodes.

 

 

Thanks & Regards

-Kalpana

 

------_=_NextPart_001_01C5D922.F1CA7560-- From rtg-bfd-bounces@ietf.org Tue Oct 25 01:56:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUHnQ-000461-VK; Tue, 25 Oct 2005 01:56:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUHnO-00045t-6q for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 01:56:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21992 for ; Tue, 25 Oct 2005 01:56:12 -0400 (EDT) Received: from www8.cruzio.com ([63.249.95.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUI0H-0006sV-UB for rtg-bfd@ietf.org; Tue, 25 Oct 2005 02:09:46 -0400 Received: from [172.16.12.139] (pcp08543197pcs.sntafe01.nm.comcast.net [68.35.73.229]) by www8.cruzio.com with ESMTP id j9P5uKbV081828; Mon, 24 Oct 2005 22:56:21 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-1--558765324 Message-Id: <4EC26AA8-039A-46B1-8D27-25806ADA83E2@juniper.net> From: Dave Katz Date: Mon, 24 Oct 2005 23:56:13 -0600 To: kalpana.yenishetti@wipro.com X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.2 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: rtg-bfd@ietf.org Subject: Re: BFD queries X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-1--558765324 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Oct 24, 2005, at 11:14 PM, kalpana.yenishetti@wipro.com wrote: > Hi > > > > I have following query from the BFD draft > > > > When a BFD session is established between two nodes in a network, > and if one of the system sends a BFD control packet with POLL bit > set to change any the Min Tx/Rx intervals and the receives response > to the previous BFD packet. This could lead to situation where > sender assuming his request for configuration change for Min Tx/Rx > intervals is declined. The intervals cannot be "declined" as they are entirely unilateral in each direction (which is an important design consideration in the protocol.) The packet with Final lets the system know that the other system has seen the change and, for example, won't time out if the sender wants to transmit at a slower rate. > If the choosen transport protocol for BFD transmission is UDP, the > FIN bit set packet is lost then there will be discrepancy the > configuration between the configured nodes. This is why the poll is sent repeatedly until a final is heard. --Dave --Apple-Mail-1--558765324 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Oct 24, 2005, = at 11:14 PM, kalpana.yenishetti@wipro.com<= /A> wrote:

Hi=A0

I have following query from the BFD = draft=A0

  1. When a BFD session is established between two = nodes in a network, and if one of the system sends a BFD control packet = with POLL bit set to change any the Min Tx/Rx intervals and the receives = response to the previous BFD packet. This could lead to situation where = sender assuming his request for configuration change for Min Tx/Rx = intervals is = declined.
The= intervals cannot be "declined" as they are entirely unilateral in each = direction (which is an important design consideration in the protocol.)=A0= The packet with Final lets the system know that the other system has = seen the change and, for example, won't time out if the sender wants to = transmit at a slower rate.

    If the choosen transport protocol for BFD = transmission is UDP, the FIN bit set packet is lost then there will be = discrepancy the configuration between the configured = nodes.
This is = why the poll is sent repeatedly until a final is heard.


= --Apple-Mail-1--558765324-- From rtg-bfd-bounces@ietf.org Tue Oct 25 02:25:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUIFg-0006hl-5g; Tue, 25 Oct 2005 02:25:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUIFe-0006hd-0n for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 02:25:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23566 for ; Tue, 25 Oct 2005 02:25:24 -0400 (EDT) From: kalpana.yenishetti@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUISL-0007fM-KA for rtg-bfd@ietf.org; Tue, 25 Oct 2005 02:38:58 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 57295205EF for ; Tue, 25 Oct 2005 11:42:28 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 372E0205D9 for ; Tue, 25 Oct 2005 11:42:28 +0530 (IST) Received: from hyd-mdp-msg.wipro.com ([10.150.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 11:54:50 +0530 Received: from HYD-MKD-MBX01.wipro.com ([10.154.50.182]) by hyd-mdp-msg.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 11:53:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D92C.9EA70DC6" Date: Tue, 25 Oct 2005 11:53:31 +0530 Message-ID: Thread-Topic: BFD queries Thread-Index: AcXZKX8oIcJ7IVf5Qdu7N60KKZkLhgAAWIkQ To: X-OriginalArrivalTime: 25 Oct 2005 06:23:37.0082 (UTC) FILETIME=[A2123DA0:01C5D92C] X-Spam-Score: 0.5 (/) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 Subject: RE: BFD queries X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D92C.9EA70DC6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Thanks Dave =20 Let me frame the question like this=20 =20 =20 1. When a BFD session is established between two nodes in a network, and if one of the system sends a BFD control packet with POLL bit set to change any the Min Tx/Rx intervals and the receives response to the previous BFD packet. This could lead to situation where sender assuming his request for configuration change for Min Tx/Rx intervals is declined. The intervals cannot be "declined" as they are entirely unilateral in each direction (which is an important design consideration in the protocol.) The packet with Final lets the system know that the other system has seen the change and, for example, won't time out if the sender wants to transmit at a slower rate. =20 1. =20 Node A Node B =20 Bfd -----Session State UP----- Bfd (session up n running on both nodes, with mandatory mode, Asynch) =20 Bfd control pkts <----------> Bfd control pkts (Noraml bfd control pkts for link connectivity ) =20 Now=20 =20 A has sent normal bfd control pkt to B and immediately it changes its Tx interval and therefore sends one more bfd control pkt with POLL bit set n change of Min Tx interval.=20 But B before processing the POLL bit received pkt sends its normal bfd control pkt for link detection.(therefore this packet will not have FIN set) Now A may conclude with the recived bfd normal control packet which does not have FIN bit set as declined parameter=20 =20 All this is b'coz the after sending the POLL bit set packet , A assumes the immediate received packet as response to the its POLL request.=20 =20 =20 1. If the choosen transport protocol for BFD transmission is UDP, the FIN bit set packet is lost then there will be discrepancy the configuration between the configured nodes. This is why the poll is sent repeatedly until a final is heard. =20 Node A Node B =20 Bfd -----Session State UP----- Bfd (session up n running on both nodes, with mandatory mode, Asynch) =20 Bfd control pkts <----------> Bfd control pkts (Noraml bfd control pkts for link connectivity ) =20 Now=20 =20 Node A sends the POLL bit set packet chaning its Tx interval, Node B agrees to the change and sedns its FIN bit set packet, and changes its Rx interval with the larger of the its Rx and received Tx. But the bfd packet from B to Node A can lost so , Node A keeps sending the POLL bit set packet but Node B has already changed its Rx interval, which Node A is not aware of b'coz of the FIN packet loss. =20 =20 --Dave =20 ------_=_NextPart_001_01C5D92C.9EA70DC6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

Thanks = Dave

 

Let me frame the question like this =

 

 

  1. When a BFD session is established between two nodes in a network, and if = one of the system sends a BFD control packet with POLL bit set to change = any the Min Tx/Rx intervals and the receives response to the previous BFD = packet. This could lead to situation where sender assuming his request for = configuration change for Min Tx/Rx intervals is = declined.

The intervals cannot be "declined" as they are entirely unilateral in each direction (which is an important design consideration in the protocol.)  The packet with Final lets the = system know that the other system has seen the change and, for example, won't = time out if the sender wants to transmit at a slower = rate.

 

=

1.

 

Node A =             &= nbsp;           &n= bsp;           Node B

 

Bfd    -----Session = State UP-----   Bfd (session up n running on both nodes, with = mandatory mode, Asynch)

 

Bfd control pkts  = ß------à Bfd control = pkts (Noraml bfd control pkts for link connectivity )

 

Now

 

A has sent normal bfd control pkt = to B and immediately it changes its Tx interval and therefore sends one more bfd = control pkt with POLL bit set n change of Min Tx interval. =

But B before processing the POLL = bit received pkt sends its normal bfd control pkt for link detection.(therefore this = packet will not have FIN set)

Now A may conclude with the recived = bfd normal control packet which does not have FIN bit set as declined parameter =

 

All this is b’coz the after = sending the POLL bit set packet , A assumes the immediate received packet as = response to the its POLL request.

 

 



  1. If the choosen transport protocol for BFD transmission is UDP, the FIN = bit set packet is lost then there will be discrepancy the configuration between the configured nodes.

This is why the poll is sent repeatedly until a final is = heard.

 

Node A =             &= nbsp;           &n= bsp;           Node B

 

Bfd    -----Session = State UP-----   Bfd (session up n running on both nodes, with = mandatory mode, Asynch)

 

Bfd control pkts  = ß------à Bfd control = pkts (Noraml bfd control pkts for link connectivity )

 

Now

 

Node A sends the POLL bit set = packet chaning its Tx interval, Node B agrees to the change and sedns its FIN bit set = packet, and changes its Rx interval with the larger of the its Rx and received Tx. = But the bfd packet from B to Node A can lost so , Node A keeps sending the POLL bit = set packet but Node B has already changed its Rx interval, which Node A is not = aware of b’coz of the FIN packet loss.

 

 

--Dave

 

------_=_NextPart_001_01C5D92C.9EA70DC6-- From rtg-bfd-bounces@ietf.org Tue Oct 25 04:19:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJuQ-0004D7-9R; Tue, 25 Oct 2005 04:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJuO-0004D2-8N for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 04:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28928 for ; Tue, 25 Oct 2005 04:11:33 -0400 (EDT) Received: from www8.cruzio.com ([63.249.95.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUK7J-0002CP-1n for rtg-bfd@ietf.org; Tue, 25 Oct 2005 04:25:09 -0400 Received: from [172.16.12.139] (pcp08543197pcs.sntafe01.nm.comcast.net [68.35.73.229]) by www8.cruzio.com with ESMTP id j9P8BjbV079543; Tue, 25 Oct 2005 01:11:45 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-2--550640380 Message-Id: From: Dave Katz Date: Tue, 25 Oct 2005 02:11:38 -0600 To: kalpana.yenishetti@wipro.com X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.6 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: rtg-bfd@ietf.org Subject: Re: BFD queries X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-2--550640380 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable On Oct 25, 2005, at 12:23 AM, kalpana.yenishetti@wipro.com wrote: > > A has sent normal bfd control pkt to B and immediately it changes =20 > its Tx interval and therefore sends one more bfd control pkt with =20 > POLL bit set n change of Min Tx interval. > > But B before processing the POLL bit received pkt sends its normal =20 > bfd control pkt for link detection.(therefore this packet will not =20 > have FIN set) > > Now A may conclude with the recived bfd normal control packet which =20= > does not have FIN bit set as declined parameter I'm not sure what you mean by "declined parameter," there is no such =20 thing. Parameters in BFD are not "negotiated" in the normal way; =20 rather, each side announces its timing parameters and the other side =20 MUST obey them (and choose the largest value of each pair, e.g. my TX =20= and your RX.) > > > All this is b=92coz the after sending the POLL bit set packet , A =20 > assumes the immediate received packet as response to the its POLL =20 > request. There is no such thing as a "response" in BFD, except for a packet =20 with Final in response to a Poll. If A sends a Poll and B sends a =20 Final in response and there were other packets in the pipeline, that =20 are received before the Final, it makes no difference. A will =20 process them as normal and wait to implement its parameter changes =20 until it sees the Final. > > Node A sends the POLL bit set packet chaning its Tx interval, Node =20 > B agrees to the change and sedns its FIN bit set packet, and =20 > changes its Rx interval with the larger of the its Rx and received =20 > Tx. But the bfd packet from B to Node A can lost so , Node A keeps =20 > sending the POLL bit set packet but Node B has already changed its =20 > Rx interval, which Node A is not aware of b=92coz of the FIN packet =20= > loss. There is no "agreeing" in BFD. All parameters changes are mandatory =20 and unilateral. This gives each system full control over both the =20 transmit and receive load (of BFD packets.) In this case, assuming A is increasing its TX interval, B will =20 increase the detection time in response to the change, but A will =20 continue to transmit at the earlier, more rapid rate, and will =20 continue to send packets with Poll. Eventually one of the Finals =20 will get through and A will slow down its transmission rate. The =20 procedures are designed to avoid accidentally having a session =20 failure because one side slowed down its transmission rate before the =20= other increased the detection time. There is no harm in sending =20 packets too often (within the offered RX limit, of course.) --Dave= --Apple-Mail-2--550640380 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

=A0

All this is b=92coz the after sending the POLL bit set = packet , A assumes the immediate received packet as response to the its = POLL = request.


There is no such thing as a = "response" in BFD, except for a packet with Final in response to a = Poll.=A0 If A sends a Poll and B sends a Final in response and there = were other packets in the pipeline, that are received before the Final, = it makes no difference.=A0 A will process them as normal and wait to = implement its parameter changes until it sees the Final.


Node A sends the POLL bit set packet chaning its Tx = interval, Node B agrees to the change and sedns its FIN bit set packet, = and changes its Rx interval with the larger of the its Rx and received = Tx. But the bfd packet from B to Node A can lost so , Node A keeps = sending the POLL bit set packet but Node B has already changed its Rx = interval, which Node A is not aware of b=92coz of the FIN packet = loss.


There is no "agreeing" in BFD.=A0 = All parameters changes are mandatory and unilateral.=A0 This gives each = system full control over both the transmit and receive load (of BFD = packets.)

In = this case, assuming A is increasing its TX interval, B will increase the = detection time in response to the change, but A will continue to = transmit at the earlier, more rapid rate, and will continue to send = packets with Poll.=A0 Eventually one of the Finals will get through and = A will slow down its transmission rate.=A0 The procedures are designed = to avoid accidentally having a session failure because one side slowed = down its transmission rate before the other increased the detection = time.=A0 There is no harm in sending packets too often (within the = offered RX limit, of course.)

--Dave
= --Apple-Mail-2--550640380-- From rtg-bfd-bounces@ietf.org Tue Oct 25 06:22:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EULwc-0006pB-QJ; Tue, 25 Oct 2005 06:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EULwa-0006nn-RI for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 06:22:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04999 for ; Tue, 25 Oct 2005 06:21:57 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUM9W-0005L3-KI for rtg-bfd@ietf.org; Tue, 25 Oct 2005 06:35:35 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9PAM2T21260 for ; Tue, 25 Oct 2005 13:22:02 +0300 Date: Tue, 25 Oct 2005 13:22:02 +0300 (EEST) From: Pekka Savola To: rtg-bfd@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: document layout for singlehop, multihop and generic X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, I'm still puzzled by the coverage of various documents: 1) bfd-multihop-03: about 3 pages of very generic (non-protocol specific) guidance on multihop BFD sessions. 2) bfd-v4v6-1hop-04: the first 4.5 pages are very generic single-hop BGP guidance (applicable to any single hop BFD application), the next 4 pages detail a number of OSPF/IS-IS details for single-hop cases 3) bfd-generic-01: about 5 pages of generic BFD guidance (not specific to either single or multihop). This seems like patchwork. IMHO, a more logical separation might be having everything generic (either single or multihop) in one document and moving the protocol-specific details out of v2v6-1hop to a separate BFD+OSPF/ISIS document. -- 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 rtg-bfd-bounces@ietf.org Tue Oct 25 06:28:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUM2r-0000RJ-Ub; Tue, 25 Oct 2005 06:28:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUM2p-0000Mc-Mg for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 06:28:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05345 for ; Tue, 25 Oct 2005 06:28:26 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUMFl-0005Y6-Hv for rtg-bfd@ietf.org; Tue, 25 Oct 2005 06:42:02 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9PASTP21398 for ; Tue, 25 Oct 2005 13:28:29 +0300 Date: Tue, 25 Oct 2005 13:28:28 +0300 (EEST) From: Pekka Savola To: rtg-bfd@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: BFD w/ static routes and single-hop eBGP X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, I still want to see the details of BFD with: - single-hop static routes - single-hop eBGP .. in some document. At the last meeting, David said that he didn't believe these are necessary as the bfd-generic-01 doc includes this information but I disagree. Even if the details are trivial (they may or may not be), as an operator I think it's vital to see them spelled out anywhere so that we can point vendors to a specific section of a spec in CFTs and ensure the protocols will be interoperable. I suggest a section or two either in the main body of the spec or in an appendix either in draft-ietf-bfd-v4v6-1hop or draft-ietf-bfd-generic. All of this would likely fit in one or two pages -- and if not, that would be even stronger reason that those details must be written out. At least one deployed implementation of static routes + BFD already exists. -- 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 rtg-bfd-bounces@ietf.org Tue Oct 25 07:21:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUMs0-0001pZ-6D; Tue, 25 Oct 2005 07:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUMry-0001oI-Lx for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 07:21:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07539 for ; Tue, 25 Oct 2005 07:21:16 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUN4u-0006lH-AV for rtg-bfd@ietf.org; Tue, 25 Oct 2005 07:34:53 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOW00LZPY3C3L@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Tue, 25 Oct 2005 19:18:49 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOW00DBVY3CPC@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Tue, 25 Oct 2005 19:18:48 +0800 (CST) Received: from z11024 ([10.110.100.87]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOW00EVHY34T2@szxml02-in.huawei.com>; Tue, 25 Oct 2005 19:18:40 +0800 (CST) Date: Tue, 25 Oct 2005 19:10:56 +0800 From: Suping Zhai To: Pekka Savola , bfd Message-id: <0IOW00EVJY34T2@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7BIT Cc: Subject: Re: document layout for singlehop, multihop and generic X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Pekka, I have the same feeling with you. In fact before last 63th meeting, including me and you, some other people provide the alike concern. Based on the your suggestions I propose further that the following separation be considered in the upcoming meeting, and to have a logical assignment for various documents: 1) First bfd-generic-01 is a common guidance for all the bfd draft, for the generic purpose, 2) Second bfd-multihop-xx, bfd-v4v6-1hop-xx, bfd-mpls-xx separately describe the specific deployment of BFD in various situations if the generic document doesn't cover; 3) Last the protocol specific descriptions e.g. OSFP/ISIS/BGP(IBGP and EBGP)/RIPv2 with BFD are given out in detail, including the bootstrap methods, interactions etc in the very specific environment. Since that almost all documents have been in a relative stable state, it's not very difficult to seperate the existing draft according to the above rules. Hope that BFD work group will produce a set of sensible documents for the vendors or operators to follow. Best Regards, Suping >Hi, > >I'm still puzzled by the coverage of various documents: > > 1) bfd-multihop-03: about 3 pages of very generic (non-protocol >specific) guidance on multihop BFD sessions. > > 2) bfd-v4v6-1hop-04: the first 4.5 pages are very generic single-hop >BGP guidance (applicable to any single hop BFD application), the next >4 pages detail a number of OSPF/IS-IS details for single-hop cases > > 3) bfd-generic-01: about 5 pages of generic BFD guidance (not >specific to either single or multihop). > >This seems like patchwork. IMHO, a more logical separation might be >having everything generic (either single or multihop) in one document >and moving the protocol-specific details out of v2v6-1hop to a >separate BFD+OSPF/ISIS document. > >-- >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 rtg-bfd-bounces@ietf.org Tue Oct 25 08:26:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUNsY-0007Xm-CR; Tue, 25 Oct 2005 08:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUNsW-0007XR-Fl for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 08:26:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13228 for ; Tue, 25 Oct 2005 08:25:54 -0400 (EDT) From: kalpana.yenishetti@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUO4u-0000rV-Cx for rtg-bfd@ietf.org; Tue, 25 Oct 2005 08:39:32 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 54D5C206BA for ; Tue, 25 Oct 2005 17:42:47 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 37FE8205DD for ; Tue, 25 Oct 2005 17:42:47 +0530 (IST) Received: from hyd-mdp-msg02.wipro.com ([10.150.49.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 17:55:09 +0530 Received: from HYD-MKD-MBX01.wipro.com ([10.154.50.182]) by hyd-mdp-msg02.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 17:54:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D95F.0DDF61AF" Date: Tue, 25 Oct 2005 17:54:32 +0530 Message-ID: Thread-Index: AcXZYBcA7vqq9d51Rwq8xbFw+vHCtQ== To: X-OriginalArrivalTime: 25 Oct 2005 12:24:32.0344 (UTC) FILETIME=[0D9CFD80:01C5D95F] X-Spam-Score: 0.4 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: (no subject) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D95F.0DDF61AF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi=20 =20 How BFD handles simple password authentication? =20 Draft says,=20 =20 In this method of authentication, one or more Passwords (with corresponding Key IDs) are configured in each system and one of these Password/ID pairs is carried in each BFD Control packet. The receiving system accepts the packet if the Password and Key ID matches one of the Password/ID pairs configured in that system. =20 =20 How the Node B knows about the configured Password/IDs in Node A, to validate? =20 Thanks & Regards -Kalpana =20 ------_=_NextPart_001_01C5D95F.0DDF61AF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi

 

How BFD handles simple password = authentication?

 

Draft says,

 

In this method of =
authentication,
   one or more Passwords (with =
corresponding Key IDs) are configured =
in
   each system and one of these =
Password/ID pairs is carried in each =
BFD
   Control packet.  The =
receiving system accepts the packet if =
the
   Password and Key ID matches one =
of the Password/ID pairs =
configured
   in that =
system.

 

 

How the Node B knows about the configured = Password/IDs in Node A, to validate?

 

Thanks & Regards

-Kalpana

 

------_=_NextPart_001_01C5D95F.0DDF61AF-- From rtg-bfd-bounces@ietf.org Tue Oct 25 10:50:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQ8S-0003l3-Q0; Tue, 25 Oct 2005 10:50:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQ8R-0003km-8u for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 10:50:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21395 for ; Tue, 25 Oct 2005 10:50:28 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQLP-0004uo-Sr for rtg-bfd@ietf.org; Tue, 25 Oct 2005 11:04:08 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Oct 2005 07:50:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="13829723:sNHT23198848" Received: from [10.86.165.254] (dhcp-10-86-165-254.cisco.com [10.86.165.254]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9PEoUEi011898; Tue, 25 Oct 2005 10:50:31 -0400 (EDT) In-Reply-To: <0IOW00EVJY34T2@szxml02-in.huawei.com> References: <0IOW00EVJY34T2@szxml02-in.huawei.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Tue, 25 Oct 2005 10:50:30 -0400 To: zhaisuping@huawei.com X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: bfd , Pekka Savola Subject: Re: document layout for singlehop, multihop and generic X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org I personally think the current structure is fine. --Tom > Hi Pekka, > I have the same feeling with you. In fact before last 63th meeting, > including me and you, some other people provide the alike concern. > Based on the your suggestions I propose further that the following > separation be considered in the upcoming meeting, and to have a > logical assignment for various documents: > 1) First bfd-generic-01 is a common guidance for all the bfd draft, > for the generic purpose, > 2) Second bfd-multihop-xx, bfd-v4v6-1hop-xx, bfd-mpls-xx separately > describe the specific deployment of BFD in various situations if > the generic document doesn't cover; > 3) Last the protocol specific descriptions e.g. OSFP/ISIS/BGP(IBGP > and EBGP)/RIPv2 with BFD are given out in detail, including the > bootstrap methods, interactions etc in the very specific environment. > > Since that almost all documents have been in a relative stable > state, it's not very difficult to seperate the existing draft > according to the above rules. > > Hope that BFD work group will produce a set of sensible documents > for the vendors or operators to follow. > > Best Regards, > Suping > >> Hi, >> >> I'm still puzzled by the coverage of various documents: >> >> 1) bfd-multihop-03: about 3 pages of very generic (non-protocol >> specific) guidance on multihop BFD sessions. >> >> 2) bfd-v4v6-1hop-04: the first 4.5 pages are very generic single-hop >> BGP guidance (applicable to any single hop BFD application), the next >> 4 pages detail a number of OSPF/IS-IS details for single-hop cases >> >> 3) bfd-generic-01: about 5 pages of generic BFD guidance (not >> specific to either single or multihop). >> >> This seems like patchwork. IMHO, a more logical separation might be >> having everything generic (either single or multihop) in one document >> and moving the protocol-specific details out of v2v6-1hop to a >> separate BFD+OSPF/ISIS document. >> >> -- >> 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 rtg-bfd-bounces@ietf.org Tue Oct 25 11:14:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQVY-0000yo-Ox; Tue, 25 Oct 2005 11:14:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQVX-0000yg-0j for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 11:14:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28541 for ; Tue, 25 Oct 2005 11:14:19 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQiU-0007dd-S9 for rtg-bfd@ietf.org; Tue, 25 Oct 2005 11:28:00 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2005 08:14:25 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="356446178:sNHT28233164" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9PFDYuv021301; Tue, 25 Oct 2005 08:14:22 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 11:14:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2005 11:14:08 -0400 Message-ID: Thread-Topic: document layout for singlehop, multihop and generic Thread-Index: AcXZVmvmng3iioVHRJWsPbZlakrnxAAH2cpQ From: "Zafar Ali \(zali\)" To: , "Pekka Savola" , "bfd" X-OriginalArrivalTime: 25 Oct 2005 15:14:09.0332 (UTC) FILETIME=[BF921F40:01C5D976] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: document layout for singlehop, multihop and generic X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Suping and Pekka,=20 This will certainly catch us in the Law of Diminishing Return. =20 Thanks Regards... Zafar =20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Suping Zhai > Sent: Tuesday, October 25, 2005 7:11 AM > To: Pekka Savola; bfd > Subject: Re: document layout for singlehop, multihop and generic >=20 > Hi Pekka, > I have the same feeling with you. In fact before last 63th=20 > meeting, including me and you, some other people provide the=20 > alike concern. > Based on the your suggestions I propose further that the=20 > following separation be considered in the upcoming meeting,=20 > and to have a logical assignment for various documents: > 1) First bfd-generic-01 is a common guidance for all the bfd=20 > draft, for the generic purpose, > 2) Second bfd-multihop-xx, bfd-v4v6-1hop-xx, bfd-mpls-xx=20 > separately describe the specific deployment of BFD in various=20 > situations if the generic document doesn't cover; > 3) Last the protocol specific descriptions e.g.=20 > OSFP/ISIS/BGP(IBGP and EBGP)/RIPv2 with BFD are given out in=20 > detail, including the bootstrap methods, interactions etc in=20 > the very specific environment. >=20 > Since that almost all documents have been in a relative=20 > stable state, it's not very difficult to seperate the=20 > existing draft according to the above rules. >=20 > Hope that BFD work group will produce a set of sensible=20 > documents for the vendors or operators to follow. >=20 > Best Regards, > Suping > >Hi, > > > >I'm still puzzled by the coverage of various documents: > > > > 1) bfd-multihop-03: about 3 pages of very generic (non-protocol > >specific) guidance on multihop BFD sessions. > > > > 2) bfd-v4v6-1hop-04: the first 4.5 pages are very generic=20 > single-hop=20 > >BGP guidance (applicable to any single hop BFD application), the next > >4 pages detail a number of OSPF/IS-IS details for single-hop cases > > > > 3) bfd-generic-01: about 5 pages of generic BFD guidance (not=20 > >specific to either single or multihop). > > > >This seems like patchwork. IMHO, a more logical separation might be=20 > >having everything generic (either single or multihop) in one=20 > document=20 > >and moving the protocol-specific details out of v2v6-1hop to=20 > a separate=20 > >BFD+OSPF/ISIS document. > > > >--=20 > >Pekka Savola "You each name yourselves king, yet the > >Netcore Oy kingdom bleeds." > >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From rtg-bfd-bounces@ietf.org Tue Oct 25 11:19:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQa7-0005c9-Nz; Tue, 25 Oct 2005 11:19:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQa6-0005bR-8x for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 11:19:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28926 for ; Tue, 25 Oct 2005 11:19:03 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQn4-0007np-1y for rtg-bfd@ietf.org; Tue, 25 Oct 2005 11:32:43 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2005 11:19:08 -0400 X-IronPort-AV: i="3.97,250,1125892800"; d="scan'208,217"; a="74375776:sNHT40810068" Received: from cisco.com (dhcp-161-44-212-187.cisco.com [161.44.212.187]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9PFJ6Ei025051; Tue, 25 Oct 2005 11:19:06 -0400 (EDT) Message-ID: <435E4CEA.2080304@cisco.com> Date: Tue, 25 Oct 2005 11:19:06 -0400 From: Reshad Rahman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kalpana.yenishetti@wipro.com References: Content-Type: multipart/alternative; boundary="------------050900030003010608060303" X-Spam-Score: 0.6 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: rtg-bfd@ietf.org Subject: Re: (no subject) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --------------050900030003010608060303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mechanism for key exchange etc is outside the scope of the BFD protocol. Regards, Reshad. kalpana.yenishetti@wipro.com wrote: > Hi > > > > How BFD handles simple password authentication? > > > > Draft says, > > > >In this method of authentication, > > one or more Passwords (with corresponding Key IDs) are configured in > > each system and one of these Password/ID pairs is carried in each BFD > > Control packet. The receiving system accepts the packet if the > > Password and Key ID matches one of the Password/ID pairs configured > > in that system. > > > > > > How the Node B knows about the configured Password/IDs in Node A, to > validate? > > > > Thanks & Regards > > -Kalpana > > > --------------050900030003010608060303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mechanism for key exchange etc is outside the scope of the BFD protocol.

Regards,
Reshad.

kalpana.yenishetti@wipro.com wrote:

Hi

 

How BFD handles simple password authentication?

 

Draft says,

 

In this method of authentication,
   one or more Passwords (with corresponding Key IDs) are configured in
   each system and one of these Password/ID pairs is carried in each BFD
   Control packet.  The receiving system accepts the packet if the
   Password and Key ID matches one of the Password/ID pairs configured
   in that system.

 

 

How the Node B knows about the configured Password/IDs in Node A, to validate?

 

Thanks & Regards

-Kalpana

 


--------------050900030003010608060303-- From rtg-bfd-bounces@ietf.org Tue Oct 25 11:46:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUR0O-0008RM-Qs; Tue, 25 Oct 2005 11:46:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUR0N-0008RC-MK for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 11:46:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00889 for ; Tue, 25 Oct 2005 11:46:12 -0400 (EDT) Received: from www8.cruzio.com ([63.249.95.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURDL-0000FA-Bl for rtg-bfd@ietf.org; Tue, 25 Oct 2005 11:59:52 -0400 Received: from [172.16.12.139] (pcp08543197pcs.sntafe01.nm.comcast.net [68.35.73.229]) by www8.cruzio.com with ESMTP id j9PFkJbV038526; Tue, 25 Oct 2005 08:46:23 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-4--523366029 Message-Id: From: Dave Katz Date: Tue, 25 Oct 2005 09:46:12 -0600 To: kalpana.yenishetti@wipro.com X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: rtg-bfd@ietf.org Subject: Re: (no subject) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-4--523366029 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Oct 25, 2005, at 6:24 AM, kalpana.yenishetti@wipro.com wrote: > > How the Node B knows about the configured Password/IDs in Node A, > to validate? > > It's outside the scope of the spec. A time-honored method is to configure it. --Apple-Mail-4--523366029 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


= --Apple-Mail-4--523366029-- From rtg-bfd-bounces@ietf.org Tue Oct 25 11:53:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUR6j-00038v-5w; Tue, 25 Oct 2005 11:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUR6h-00038h-6N for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 11:52:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01225 for ; Tue, 25 Oct 2005 11:52:43 -0400 (EDT) Received: from www8.cruzio.com ([63.249.95.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURJg-0000Q7-9f for rtg-bfd@ietf.org; Tue, 25 Oct 2005 12:06:24 -0400 Received: from [172.16.12.139] (pcp08543197pcs.sntafe01.nm.comcast.net [68.35.73.229]) by www8.cruzio.com with ESMTP id j9PFqubV044313; Tue, 25 Oct 2005 08:52:57 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Tue, 25 Oct 2005 09:52:49 -0600 To: Pekka Savola X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: BFD w/ static routes and single-hop eBGP X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Seems like we've beaten this one to death already. For static routes, by their nature, there can be no interoperability problem as there is nothing to interoperate. I don't see what else there is to specify for eBGP. (This makes it considerably shorter than two pages.) --Dave On Oct 25, 2005, at 4:28 AM, Pekka Savola wrote: > Hi, > > I still want to see the details of BFD with: > - single-hop static routes > - single-hop eBGP > > .. in some document. At the last meeting, David said that he > didn't believe these are necessary as the bfd-generic-01 doc > includes this information but I disagree. Even if the details are > trivial (they may or may not be), as an operator I think it's vital > to see them spelled out anywhere so that we can point vendors to a > specific section of a spec in CFTs and ensure the protocols will be > interoperable. > > I suggest a section or two either in the main body of the spec or > in an appendix either in draft-ietf-bfd-v4v6-1hop or draft-ietf-bfd- > generic. > > All of this would likely fit in one or two pages -- and if not, > that would be even stronger reason that those details must be > written out. At least one deployed implementation of static routes > + BFD already exists. > > -- > 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 rtg-bfd-bounces@ietf.org Tue Oct 25 16:45:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVg4-0006ui-EX; Tue, 25 Oct 2005 16:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVg2-0006q5-Cr for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 16:45:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07218 for ; Tue, 25 Oct 2005 16:45:30 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVt2-0007Z6-5L for rtg-bfd@ietf.org; Tue, 25 Oct 2005 16:59:13 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2005 13:45:31 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="356606044:sNHT2850249352" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9PKjS94021367; Tue, 25 Oct 2005 13:45:29 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 13:45:27 -0700 Received: from [128.107.9.48] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 13:45:26 -0700 User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Tue, 25 Oct 2005 15:45:36 -0500 From: David Ward To: Pekka Savola , , David Ward , Jeffrey Haas Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Oct 2005 20:45:26.0971 (UTC) FILETIME=[079120B0:01C5D9A5] X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Subject: Re: document layout for singlehop, multihop and generic X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org We covered this at the last several WG meetings. The issue is: reorganizing the docs w/o changing the content vs getting the docs to spec ... The WG agreed to get the docs to full standard. -DWard On 10/25/05 5:22 AM, "Pekka Savola" wrote: > Hi, > > I'm still puzzled by the coverage of various documents: > > 1) bfd-multihop-03: about 3 pages of very generic (non-protocol > specific) guidance on multihop BFD sessions. > > 2) bfd-v4v6-1hop-04: the first 4.5 pages are very generic single-hop > BGP guidance (applicable to any single hop BFD application), the next > 4 pages detail a number of OSPF/IS-IS details for single-hop cases > > 3) bfd-generic-01: about 5 pages of generic BFD guidance (not > specific to either single or multihop). > > This seems like patchwork. IMHO, a more logical separation might be > having everything generic (either single or multihop) in one document > and moving the protocol-specific details out of v2v6-1hop to a > separate BFD+OSPF/ISIS document. From rtg-bfd-bounces@ietf.org Tue Oct 25 17:07:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUW0f-00018S-Nm; Tue, 25 Oct 2005 17:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUW0d-00012Q-H5 for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 17:07:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14508 for ; Tue, 25 Oct 2005 17:06:48 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUWDe-00021Y-WE for rtg-bfd@ietf.org; Tue, 25 Oct 2005 17:20:31 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AA4DF5B3011; Tue, 25 Oct 2005 14:06:49 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22597-02; Tue, 25 Oct 2005 14:06:49 -0700 (PDT) Received: from PARBETM2XP (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 839F75B300D; Tue, 25 Oct 2005 14:06:47 -0700 (PDT) From: "Peter Arberg" To: "'David Ward'" , "'Pekka Savola'" , , "'Jeffrey Haas'" Date: Tue, 25 Oct 2005 23:06:42 +0200 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcXZpV8zeozhXwXcSieE1DNqpwdezAAAQrPQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051025210647.839F75B300D@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Subject: RE: document layout for singlehop, multihop and generic X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, I have one suggestion which I would like to see in one of the documents, best fit would proabably be in the 1hop document, but could also be in the generic one. The usage of BFD over 802.3ad ethernet link-groups, in an application to detect faults in the individual links inside the link-group. (not BFD over ethernet, but using the BFD over UDP approach) I could propose some text for this, and we can discuss it based on this, and then if you do not think it belongs in either of these document, or it is to late in the game to propose changes, then I could create a new internet-draft with a suggestion for this functionality. thanks, Peter > -----Original Message----- > From: rtg-bfd-bounces@ietf.org > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of David Ward > Sent: 25. oktober 2005 22:46 > To: Pekka Savola; rtg-bfd@ietf.org; David Ward; Jeffrey Haas > Subject: Re: document layout for singlehop, multihop and generic > > We covered this at the last several WG meetings. The issue > is: reorganizing > the docs w/o changing the content vs getting the docs to spec > ... The WG > agreed to get the docs to full standard. > > -DWard > > > On 10/25/05 5:22 AM, "Pekka Savola" wrote: > > > Hi, > > > > I'm still puzzled by the coverage of various documents: > > > > 1) bfd-multihop-03: about 3 pages of very generic (non-protocol > > specific) guidance on multihop BFD sessions. > > > > 2) bfd-v4v6-1hop-04: the first 4.5 pages are very generic single-hop > > BGP guidance (applicable to any single hop BFD > application), the next > > 4 pages detail a number of OSPF/IS-IS details for single-hop cases > > > > 3) bfd-generic-01: about 5 pages of generic BFD guidance (not > > specific to either single or multihop). > > > > This seems like patchwork. IMHO, a more logical separation might be > > having everything generic (either single or multihop) in > one document > > and moving the protocol-specific details out of v2v6-1hop to a > > separate BFD+OSPF/ISIS document. > From rtg-bfd-bounces@ietf.org Tue Oct 25 21:29:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUa6p-0002TT-U8; Tue, 25 Oct 2005 21:29:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUa6o-0002RM-3Q for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 21:29:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11949 for ; Tue, 25 Oct 2005 21:29:27 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUaJq-0005e3-3o for rtg-bfd@ietf.org; Tue, 25 Oct 2005 21:43:12 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOY004JM1R7O6@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 26 Oct 2005 09:35:32 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOY001CY1R70B@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 26 Oct 2005 09:35:31 +0800 (CST) Received: from z11024 ([10.110.100.87]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOY00LRR1WLB3@szxml01-in.huawei.com>; Wed, 26 Oct 2005 09:38:45 +0800 (CST) Date: Wed, 26 Oct 2005 09:27:39 +0800 From: Suping Zhai To: Dave Katz , bfd , Pekka Savola Message-id: <0IOY00LRS1WLB3@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7BIT Cc: Subject: Re: Re: BFD w/ static routes and single-hop eBGP X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, Perhaps what we, at least Pekka and me, concern is that we should have a very clear definition of what eBGP should do in order to bootstrap BFD, and what is the specific interactions between BGP and BFD session. What I want to further to do is that as well as BGP, how the RIP(v2) should react when run with BFD, regarding to the BFD bootstrapping and interactions with BFD. Or else there is no strict rules to run BFD in various situations, and the result will be that the interoperation become a problem. Just a few pages can solve this problem, why do we wait and see:( Best Regards, Suping >Seems like we've beaten this one to death already. > >For static routes, by their nature, there can be no interoperability >problem as there is nothing to interoperate. > >I don't see what else there is to specify for eBGP. (This makes it >considerably shorter than two pages.) > >--Dave > >On Oct 25, 2005, at 4:28 AM, Pekka Savola wrote: > >> Hi, >> >> I still want to see the details of BFD with: >> - single-hop static routes >> - single-hop eBGP >> >> .. in some document. At the last meeting, David said that he >> didn't believe these are necessary as the bfd-generic-01 doc >> includes this information but I disagree. Even if the details are >> trivial (they may or may not be), as an operator I think it's vital >> to see them spelled out anywhere so that we can point vendors to a >> specific section of a spec in CFTs and ensure the protocols will be >> interoperable. >> >> I suggest a section or two either in the main body of the spec or >> in an appendix either in draft-ietf-bfd-v4v6-1hop or draft-ietf-bfd- >> generic. >> >> All of this would likely fit in one or two pages -- and if not, >> that would be even stronger reason that those details must be >> written out. At least one deployed implementation of static routes >> + BFD already exists. >> >> -- >> 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 rtg-bfd-bounces@ietf.org Tue Oct 25 23:51:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcJe-0007aj-4q; Tue, 25 Oct 2005 23:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcJb-0007aY-SZ for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 23:51:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19093 for ; Tue, 25 Oct 2005 23:50:48 -0400 (EDT) Received: from www8.cruzio.com ([63.249.95.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUcWh-0000sR-68 for rtg-bfd@ietf.org; Wed, 26 Oct 2005 00:04:35 -0400 Received: from [172.16.12.139] (pcp08543197pcs.sntafe01.nm.comcast.net [68.35.73.229]) by www8.cruzio.com with ESMTP id j9Q3ojhr044101; Tue, 25 Oct 2005 20:50:45 -0700 (PDT) In-Reply-To: <0IOY00LRS1WLB3@szxml01-in.huawei.com> References: <0IOY00LRS1WLB3@szxml01-in.huawei.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D16CA92-2792-4DF0-95E0-35F7D440F4D1@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Tue, 25 Oct 2005 21:50:38 -0600 To: zhaisuping@huawei.com X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: bfd , Pekka Savola Subject: Re: BFD w/ static routes and single-hop eBGP X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org I think that part of the problem here is that people view BFD as some sort of extension to other protocols, or somehow tightly coupled to them. The problem seems (at least to me) a lot less worrisome if you look at BFD as a standalone service. As such, there is no interoperability issue in the traditional sense; all compliant BFD implementations are guaranteed to interoperate, end of story. The interaction between BFD and its clients is not an interoperability issue, as it is purely an internal implementation issue. The interaction does not need to be the same (or even present) at both ends; it would be entirely reasonable for only one eBGP peer to be caring about the BFD session (which might have been bootstrapped for some other reason independent of eBGP) and it would still be useful and would still not cause interoperability issues. This is identical to other mechanisms (say, SONET alarms.) There is no specification for how OSPF interacts with SONET alarms, but it is arguably useful, and it doesn't have to be done the same way (or at all) on every system in order for things to interoperate. This is equally true of bootstrapping. The fundamental issue is in finding (or launching, if it's not there already) a BFD session that corresponds to your protocol session in terms of the identity of the neighbor. This doesn't have to be done the same way (or at all) at each end of the protocol session. For that matter, if you managed to end up with two parallel BFD sessions due to addressing issues, you could even have each end of the protocol session interacting with a *different* BFD session and it would all still work. I don't know what an explicit eBGP document would say, other than "if you don't find a BFD session to your neighbor, start one up" and "if the BFD session goes down, do something useful, like maybe pretending that the eBGP session timed out." If someone could actually point out what they think is missing and why that's important (interoperability, correctness, etc.) then maybe I'll be able to understand better what the issue is here. But I just don't get it. If anything substantive is missing, it should be added to the generic document. eBGP is just not particularly special. For that matter we could probably rip out most of the OSPF- and ISIS-specific stuff in the 1hop draft, since the techniques should be amply documented in the generic draft. I'm not too excited about revisiting those documents, however. --Dave On Oct 25, 2005, at 7:27 PM, Suping Zhai wrote: > Hi, > Perhaps what we, at least Pekka and me, concern is that we should > have a very clear definition of what eBGP should do in order to > bootstrap BFD, and what is the specific interactions between BGP > and BFD session. > What I want to further to do is that as well as BGP, how the RIP > (v2) should react when run with BFD, regarding to the BFD > bootstrapping and interactions with BFD. > Or else there is no strict rules to run BFD in various situations, > and the result will be that the interoperation become a problem. > Just a few pages can solve this problem, why do we wait and see:( > > Best Regards, > Suping > >> Seems like we've beaten this one to death already. >> >> For static routes, by their nature, there can be no interoperability >> problem as there is nothing to interoperate. >> >> I don't see what else there is to specify for eBGP. (This makes it >> considerably shorter than two pages.) >> >> --Dave >> >> On Oct 25, 2005, at 4:28 AM, Pekka Savola wrote: >> >> >>> Hi, >>> >>> I still want to see the details of BFD with: >>> - single-hop static routes >>> - single-hop eBGP >>> >>> .. in some document. At the last meeting, David said that he >>> didn't believe these are necessary as the bfd-generic-01 doc >>> includes this information but I disagree. Even if the details are >>> trivial (they may or may not be), as an operator I think it's vital >>> to see them spelled out anywhere so that we can point vendors to a >>> specific section of a spec in CFTs and ensure the protocols will be >>> interoperable. >>> >>> I suggest a section or two either in the main body of the spec or >>> in an appendix either in draft-ietf-bfd-v4v6-1hop or draft-ietf-bfd- >>> generic. >>> >>> All of this would likely fit in one or two pages -- and if not, >>> that would be even stronger reason that those details must be >>> written out. At least one deployed implementation of static routes >>> + BFD already exists. >>> >>> -- >>> 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 rtg-bfd-bounces@ietf.org Wed Oct 26 09:40:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlW6-0006no-GB; Wed, 26 Oct 2005 09:40:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlW5-0006lx-CX for rtg-bfd@megatron.ietf.org; Wed, 26 Oct 2005 09:40:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20026 for ; Wed, 26 Oct 2005 09:40:18 -0400 (EDT) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUljA-0001uc-4T for rtg-bfd@ietf.org; Wed, 26 Oct 2005 09:54:10 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with SMTP id 72143163BF5 for ; Wed, 26 Oct 2005 13:39:58 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 611JJZNn50239Mo2; Wed, 26 Oct 2005 13:39:56 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 606JJZNn40094Mo2; Wed, 26 Oct 2005 13:39:54 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.26F); Wed, 26 Oct 2005 13:39:55 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID874JJZNn43201Xo2 Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 07:39:53 -0600 Date: Wed, 26 Oct 2005 09:39:52 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Message-ID: <20051026133952.GK18406@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 26 Oct 2005 13:39:53.0814 (UTC) FILETIME=[BF084F60:01C5DA32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: Re: BFD w/ static routes and single-hop eBGP X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org [With my co-chair hat off] On Tue, Oct 25, 2005 at 01:28:28PM +0300, Pekka Savola wrote: > I still want to see the details of BFD with: > - single-hop static routes > - single-hop eBGP I'd also like to see at the least the BGP/RIP case spelled out in a little more detail. In the case of statics, it seems reasonably clear that your BFD session can be with the nexthop assigned to the static route. In the case of BGP and RIP, your session probably should be with the advertising router (RIP) or the peer (BGP) for purposes of converging the protocol up/down state. In the case where each of these protocols use first party nexthops, you will typically need this session to verify that the nexthop is reachable. The BFD session status could then be used to remove routes that can't be active due to a down session. The third party nexthop case is the more interesting one. I believe you'd want a BFD session for each third party nexthop. > .. in some document. At the last meeting, David said that he didn't > believe these are necessary as the bfd-generic-01 doc includes this > information but I disagree. In the sense that you can turn on a BFD session with any address you want, that may be clear. What's not clear is what you'd want to do per protocol. Is that your argument? > I suggest a section or two either in the main body of the spec or in > an appendix either in draft-ietf-bfd-v4v6-1hop or > draft-ietf-bfd-generic. [With my co-chair hat on] In interest in advancing the base specifications on a timely fashion, I'd say we wish to have this in the generic document. -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Wed Oct 26 10:49:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmaa-00013C-M7; Wed, 26 Oct 2005 10:49:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmaZ-0000zW-29 for rtg-bfd@megatron.ietf.org; Wed, 26 Oct 2005 10:49:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24510 for ; Wed, 26 Oct 2005 10:48:59 -0400 (EDT) Received: from nproxy.gmail.com ([64.233.182.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUmnj-0004GN-0K for rtg-bfd@ietf.org; Wed, 26 Oct 2005 11:02:52 -0400 Received: by nproxy.gmail.com with SMTP id o25so39376nfa for ; Wed, 26 Oct 2005 07:49:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WBA3npMOfqqMu249T7/DAUtmnNm/hiX7d+GvtIc63Liu2bxyrulZxzD5H5y3mkd3Eqr/MFy+UxwJKuDZc3p9mJkgRaedwNTHJNpyOAmfdc1EHIPeWBl6+qLjWkZsEQ8XkfXUic0id44n/gGJ6nogFPbC3tXfMhKm7Sbgt3IKv64= Received: by 10.49.5.10 with SMTP id h10mr222837nfi; Wed, 26 Oct 2005 07:49:11 -0700 (PDT) Received: by 10.49.2.20 with HTTP; Wed, 26 Oct 2005 07:49:11 -0700 (PDT) Message-ID: <9e31186f0510260749v2eb5a8a3g@mail.gmail.com> Date: Wed, 26 Oct 2005 16:49:11 +0200 From: Carlos Garcia Braschi To: rtg-bfd@ietf.org In-Reply-To: <435e59cb.3c6b0262.01d8.ffffb661SMTPIN_ADDED@mx.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <435e59cb.3c6b0262.01d8.ffffb661SMTPIN_ADDED@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Subject: Re: Rtg-bfd Digest, Vol 15, Issue 4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org 2005/10/25, rtg-bfd-request@ietf.org : > Date: Tue, 25 Oct 2005 09:52:49 -0600 > From: Dave Katz > Subject: Re: BFD w/ static routes and single-hop eBGP > [...] > The interaction between BFD and its clients is not an > interoperability issue, as it is purely an internal implementation > issue. The interaction does not need to be the same (or even > present) at both ends; it would be entirely reasonable for only > one eBGP peer to be caring about the BFD session (which > might have been bootstrapped for some other reason > independent of eBGP) and it would still be useful and would still > not cause interoperability issues. This is identical to other > mechanisms (say, SONET alarms.) There is no specification > for how OSPF interacts with SONET alarms, but it is arguably > useful, and it doesn't have to be done the same way (or at all) > on every system in order for things to interoperate. > > This is equally true of bootstrapping. The fundamental issue is > in finding (or launching, if it's not there already) a BFD session > that corresponds to your protocol session in terms of the > identity of the neighbor. This doesn't have to be done the same > way (or at all) at each end of the protocol session. For that > matter, if you managed to end up with two parallel BFD > sessions due to addressing issues, you could even have each > end of the protocol session interacting with a *different* BFD > session and it would all still work. These things are very good points, if they keep popping up is either because they are not so obvious in the generic draft, or something like this explanation is missing there. Although if you end up with two parallel BFD sessions I would not qualify that as interoperable implementations, as the resources used are the double than needed... > If anything substantive is missing, it should be added to > the generic document. eBGP is just not particularly special. > For that matter we could probably rip out most of the > OSPF- and ISIS-specific stuff in the 1hop draft, since the > techniques should be amply documented in the generic draft. > I'm not too excited about revisiting those documents, however. I think the most obvious thing out of place in the drafts right now is that the whole section 7 in the one-hop draft deals with some non-BFD questions specifically for OSPF and IS-IS (interaction, bootstrapping, adjacencies, graceful restart and virtual links), that from this point of view ("nothing needed is missing to use BFD for BGP") are not needed for interoperability of OSPF or a generic 1hop situation (for example, graceful restart comes to mind as not being 1hop- or OSPF- specific). BTW, I think all of that section 7 could apply for BGP also (it also has graceful restart, adjacencies and so on). The easiest way out would be to rip it away... or at least rip the references to specific protocols. Taking something away from a draft should not hurt in terms of moving it forward. I don't know once you take that part away if there is interest in mentioning anyway those issues that may appear for each protocols (inter-level interaction, session bootstrapping, graceful restart and virtual links) in another document, be it normative (generic draft) or informative (an annex of the generic draft or an informational RFC). An alternative to this ripping is to mention those issues for all the protocols on the table right now... the issues would be very similar for all, and would mostly correspond to the five points of section 7. That is probably not what we want... That still leaves us with the question of having something to be used as a reference for CFT. It seems that you point as the generic draft as the only thing needed. There are many manufacturers here on the list, is there anyone needing more detail than what is described on the generic draft? (Suping probably could help in that, being a non-neutral third party). In any case I favor any way out that could kill this issue and let the draft move on... Regards, Carlos. -- Telefonica Empresas > --Dave > > On Oct 25, 2005, at 4:28 AM, Pekka Savola wrote: > > > Hi, > > > > I still want to see the details of BFD with: > > - single-hop static routes > > - single-hop eBGP > > > > .. in some document. At the last meeting, David said that he > > didn't believe these are necessary as the bfd-generic-01 doc > > includes this information but I disagree. Even if the details are > > trivial (they may or may not be), as an operator I think it's vital > > to see them spelled out anywhere so that we can point vendors to a > > specific section of a spec in CFTs and ensure the protocols will be > > interoperable. > > > > I suggest a section or two either in the main body of the spec or > > in an appendix either in draft-ietf-bfd-v4v6-1hop or draft-ietf-bfd- > > generic. > > > > All of this would likely fit in one or two pages -- and if not, > > that would be even stronger reason that those details must be > > written out. At least one deployed implementation of static routes > > + BFD already exists. > > > > -- > > 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 rtg-bfd-bounces@ietf.org Wed Oct 26 12:58:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUobF-0001EB-WA; Wed, 26 Oct 2005 12:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUobB-0001Dw-TD for rtg-bfd@megatron.ietf.org; Wed, 26 Oct 2005 12:58:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07255 for ; Wed, 26 Oct 2005 12:57:45 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUooM-0001iJ-OA for rtg-bfd@ietf.org; Wed, 26 Oct 2005 13:11:40 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 17:57:49 +0100 Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Oct 2005 17:57:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Oct 2005 17:57:47 +0100 Message-ID: Thread-Topic: document layout for singlehop, multihop and generic Thread-Index: AcXZpV8zeozhXwXcSieE1DNqpwdezAAAQrPQAAiLc9A= To: , , , , X-OriginalArrivalTime: 26 Oct 2005 16:57:48.0674 (UTC) FILETIME=[65002620:01C5DA4E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: document layout for singlehop, multihop and generic X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Peter, I fail to see how using BFD to detect component link failures in a = link-group will be useful, perhaps you can provide more details on your = proposal?=20 If an individual link fails then the traffic using the failed link = should be switched over to one of the other links in the link-group, = i.e. as long as at least one link in the link-group is up and has enough = bandwidth available, no packets should be dropped (including BFD over = UDP packets). For distributed BFD implementations where BFD packets are = generated/processed on a per line card basis, it might be possible to = check that a BFD packet for a particular session is received via the = correct link. However, depending on the system architecture, checking = which link a BFD packet is received on may be complex/costly if not = impossible for implementations that use a centralised CPU for BFD packet = generation/processing. This restricts the applicability of your proposal = to either (i) using BFD to detect link failures as a backup measure in = case the 802.3ad component link failure mechanism isn't working, or (ii) = providing failure detection faster than the average/maximum 802.3ad link = failure detection time. Regarding (i), if 802.3ad link failure detection isn't working then = there is obviously a problem so its quite likely that BFD will also be = effected (especially as the BFD session setup and state maintenance will = somehow need to be linked to the 802.3ad load balancing = policy/algorithm). Regarding (ii), the 802.3ad implementations that I = know of use some kind of polling to detect component link failures. = Failure detection time is normally between 1-100ms, depending on when = the next poll is due when the failure occurs. IMO an average link = failure detection time of 50ms is more than fast enough for most if not = all applications. There are also other factors that need to be considered as well such = binding both directions to the same component link (particularly when = using systems with different 802.3ad load balancing = policies/algorithms), and issues caused by intermediate hops between the = BFD systems also running 802.3ad. In general, IMO it is not sensible to use an IP/UDP based protocol to = detect component link failures for a link aggregation mechanism that has = been purposely designed to be transparent to IP/UDP. Regards, Richard > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On > Behalf Of Peter Arberg > Sent: 25 October 2005 22:07 > To: 'David Ward'; 'Pekka Savola'; rtg-bfd@ietf.org; 'Jeffrey Haas' > Subject: RE: document layout for singlehop, multihop and generic >=20 >=20 > Hi, >=20 > I have one suggestion which I would like to see in one of the > documents, best fit would proabably be in the 1hop document, > but could also be in the generic one. >=20 > The usage of BFD over 802.3ad ethernet link-groups, in an > application to detect faults in the individual links inside > the link-group. >=20 > (not BFD over ethernet, but using the BFD over UDP approach) >=20 > I could propose some text for this, and we can discuss it > based on this, and then if you do not think it belongs in either=20 > of these document, or it is to late in the game to propose > changes, then I could create a new internet-draft with a=20 > suggestion for this functionality. >=20 > thanks, > Peter >=20 > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org=20 > > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of David Ward > > Sent: 25. oktober 2005 22:46 > > To: Pekka Savola; rtg-bfd@ietf.org; David Ward; Jeffrey Haas > > Subject: Re: document layout for singlehop, multihop and generic > >=20 > > We covered this at the last several WG meetings. The issue=20 > > is: reorganizing > > the docs w/o changing the content vs getting the docs to spec=20 > > ... The WG > > agreed to get the docs to full standard. > >=20 > > -DWard > >=20 > >=20 > > On 10/25/05 5:22 AM, "Pekka Savola" wrote: > >=20 > > > Hi, > > >=20 > > > I'm still puzzled by the coverage of various documents: > > >=20 > > > 1) bfd-multihop-03: about 3 pages of very generic (non-protocol > > > specific) guidance on multihop BFD sessions. > > >=20 > > > 2) bfd-v4v6-1hop-04: the first 4.5 pages are very generic=20 > single-hop > > > BGP guidance (applicable to any single hop BFD=20 > > application), the next > > > 4 pages detail a number of OSPF/IS-IS details for single-hop cases > > >=20 > > > 3) bfd-generic-01: about 5 pages of generic BFD guidance (not > > > specific to either single or multihop). > > >=20 > > > This seems like patchwork. IMHO, a more logical=20 > separation might be > > > having everything generic (either single or multihop) in=20 > > one document > > > and moving the protocol-specific details out of v2v6-1hop to a > > > separate BFD+OSPF/ISIS document. > >=20 >=20 >=20 >=20 From rtg-bfd-bounces@ietf.org Wed Oct 26 13:13:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoqE-0007rg-PN; Wed, 26 Oct 2005 13:13:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoqC-0007rY-Ab for rtg-bfd@megatron.ietf.org; Wed, 26 Oct 2005 13:13:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08192 for ; Wed, 26 Oct 2005 13:13:16 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUp3L-0002CW-KL for rtg-bfd@ietf.org; Wed, 26 Oct 2005 13:27:11 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 26 Oct 2005 10:13:19 -0700 X-IronPort-AV: i="3.97,254,1125903600"; d="scan'208"; a="357067758:sNHT25232606" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9QHCfvB019248; Wed, 26 Oct 2005 10:13:17 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 10:13:15 -0700 Received: from [171.71.139.74] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 10:13:11 -0700 User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Wed, 26 Oct 2005 12:13:22 -0500 From: David Ward To: Jeffrey Haas , , Dave Katz , David Ward Message-ID: In-Reply-To: <20051026133952.GK18406@nexthop.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Oct 2005 17:13:11.0971 (UTC) FILETIME=[8B541730:01C5DA50] X-Spam-Score: 1.1 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: Subject: Re: BFD w/ static routes and single-hop eBGP X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Jeff - On 10/26/05 8:39 AM, "Jeffrey Haas" wrote: > [With my co-chair hat off] > > On Tue, Oct 25, 2005 at 01:28:28PM +0300, Pekka Savola wrote: >> I still want to see the details of BFD with: >> - single-hop static routes >> - single-hop eBGP > > I'd also like to see at the least the BGP/RIP case spelled out in > a little more detail. What you are saying below is that you want to see the single hop EBGP clearly spell out that you should not use GR mechanisms (we left it generically stated as it is clear and didn't spell out a MUST). More below > > In the case of statics, it seems reasonably clear that your BFD session > can be with the nexthop assigned to the static route. > > In the case of BGP and RIP, your session probably should be with > the advertising router (RIP) or the peer (BGP) for purposes of > converging the protocol up/down state. In the case where each of > these protocols use first party nexthops, you will typically need > this session to verify that the nexthop is reachable. DWARD: Sure, this is what will happen w/ the protocol bootstrapping. I am not sure how to make this clearer than the current wording. The BFD session > status could then be used to remove routes that can't be active due > to a down session. > This is stated already. > The third party nexthop case is the more interesting one. I believe > you'd want a BFD session for each third party nexthop. > I disagree here. The reason being ... What do you care about the intermediate NHs wrt the EBGP bootstrapping since you can route to/through different intermediate NH? The routes and peering session is still valid. In addition, within the BGP MH scenarion; GR may be applicable (it may be not in "your case" therefore "your choice"). As stated, you don't really care about the intermediate nodes as you would then bootstrap the intermediate nodes via the underlying protocol that is directing you through those intermediate nodes. E.g. Multisession EBGP via a static route; the static route would do the bootstrapping in this case. EBGP MH is of course, a 'routed' session like IBGP and thus, see text on layering of control protocols. >> .. in some document. At the last meeting, David said that he didn't >> believe these are necessary as the bfd-generic-01 doc includes this >> information but I disagree. > > In the sense that you can turn on a BFD session with any address you want, > that may be clear. What's not clear is what you'd want to do per > protocol. Is that your argument? > >> I suggest a section or two either in the main body of the spec or in >> an appendix either in draft-ietf-bfd-v4v6-1hop or >> draft-ietf-bfd-generic. > > [With my co-chair hat on] > > In interest in advancing the base specifications on a timely fashion, > I'd say we wish to have this in the generic document. We will attempt to hack what I wrote above into clearer draft language. -DWard From rtg-bfd-bounces@ietf.org Thu Oct 27 17:25:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFFL-0000pP-Dr; Thu, 27 Oct 2005 17:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFFK-0000ox-9H for rtg-bfd@megatron.ietf.org; Thu, 27 Oct 2005 17:25:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18248 for ; Thu, 27 Oct 2005 17:24:57 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVFSk-0001FL-3u for rtg-bfd@ietf.org; Thu, 27 Oct 2005 17:39:07 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0BE33BB72E5; Thu, 27 Oct 2005 14:24:54 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04068-08; Thu, 27 Oct 2005 14:24:53 -0700 (PDT) Received: from PARBETM2XP (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id E5560BB72E4; Thu, 27 Oct 2005 14:24:51 -0700 (PDT) From: "Peter Arberg" To: , , , , Date: Thu, 27 Oct 2005 23:24:31 +0200 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXZpV8zeozhXwXcSieE1DNqpwdezAAAQrPQAAiLc9AAR5nkUA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Message-Id: <20051027212451.E5560BB72E4@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: 7bit Cc: Subject: RE: document layout for singlehop, multihop and generic X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Richard, I have added some comments and answers inline in the email. > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: 26. oktober 2005 18:58 > To: parberg@redback.com; dward@cisco.com; pekkas@netcore.fi; > rtg-bfd@ietf.org; jhaas@nexthop.com > Subject: RE: document layout for singlehop, multihop and generic > > Peter, > > I fail to see how using BFD to detect component link failures > in a link-group will be useful, perhaps you can provide more > details on your proposal? Sure. The idea of using BFD on individual links inside a link-group is no difference than using BFD as link failure detection on single links. It is for bidirectional link failure detection as well as fast detection of failure. > If an individual link fails then the traffic using the failed > link should be switched over to one of the other links in the > link-group, i.e. as long as at least one link in the > link-group is up and has enough bandwidth available, no > packets should be dropped (including BFD over UDP packets). Yes, but the link-group implementation still have to detect that the link is down to avoid using the individual link. Some link-group implementations are using static group configuration, and as such no LACP to detect if each individual link is active and as such the link failure detection is dependant on light out. In this case having a bidirectional link failure detection like BFD will be beneficial, as relying on light out have the possibility of creating unidirectional failures and as such blackholing of packets. > For distributed BFD implementations where BFD packets are > generated/processed on a per line card basis, it might be > possible to check that a BFD packet for a particular session > is received via the correct link. Correct, that was the idea we have been investigating, and as such initiate n*BFD sessions, 1 per link in the link-group, all with the same ip-source and ip-destination address, but all with different my & yours discriminators. > However, depending on the > system architecture, checking which link a BFD packet is > received on may be complex/costly if not impossible for > implementations that use a centralised CPU for BFD packet > generation/processing. Agree, there can be some possible architectures which will have more difficulty doing the proposed solution than others, but all in all it should be doable for all architectures with varying degree of speed. And is this not the case for all features, that some architectures are better suited than others for specific functionalities. > This restricts the applicability of > your proposal to either (i) using BFD to detect link failures > as a backup measure in case the 802.3ad component link > failure mechanism isn't working, or (ii) providing failure > detection faster than the average/maximum 802.3ad link > failure detection time. The idea was to use BFD in case eihter LACP is not present, or a faster link failure detection is needed than normal LACP implementations will provide. LACP is typical a control protocol, and as such implemented on system route processors, or central control units in network equipment, and as such the speed where it can detect and react to a link failure can vary, but are seldom in 10's of milliseconds. > > Regarding (i), if 802.3ad link failure detection isn't > working then there is obviously a problem so its quite likely > that BFD will also be effected (especially as the BFD session > setup and state maintenance will somehow need to be linked to > the 802.3ad load balancing policy/algorithm). The only thing in common BFD will have to the 802.3ad load-balance as I see it is the fact that different BFD sessions need to be setup on individual links inside the link-group. As soon as a BFD session is assosiated with the link, it is as such independant of if the link is a seperate link or part of a link-group, it will run as a independant BFD session. > Regarding (ii), > the 802.3ad implementations that I know of use some kind of > polling to detect component link failures. Failure detection > time is normally between 1-100ms, depending on when the next > poll is due when the failure occurs. IMO an average link > failure detection time of 50ms is more than fast enough for > most if not all applications. Yes I agree that in the case of a link component failure is in fact bidirectional, then each ends of a link-group can react fast to the "light out" condition and as such retract the link from the link-group in this case BFD will be of no help. In the case where a uni-directional failure happens, and one peer have to signal to the other peer that a failure has occured, a lot of packets will be lost, and it is in this scenario BFD will be useful, and should be able to bring us down into the 50msec. time for all kind of link-failures inside a link-group. > There are also other factors that need to be considered as > well such binding both directions to the same component link > (particularly when using systems with different 802.3ad load > balancing policies/algorithms), and issues caused by > intermediate hops between the BFD systems also running 802.3ad. I agree more study is needed in the case of intermediate systems running 802.3ad link-groups, but if we look at this in a "single hop, or direct connected" solution, then I don't think there will be any issues no matter what kind of load-balancing algorithm each peer uses, as the BFD sessions will not be part of the load-balancing. A BFD session will be tied to a link, and as such as long as both systems can agree to tied it to the same link as packets initially are received on, then there should be no issues. > In general, IMO it is not sensible to use an IP/UDP based > protocol to detect component link failures for a link > aggregation mechanism that has been purposely designed to be > transparent to IP/UDP. I'm not sure I understand why not, other links are transparent to IP/UDP, and as such used to transport IP/UDP and yet we use BFD to detect failures of these links. Individual links inside a link-group will from BFD perspective be treated as a single link. I'm not looking at running BFD detection on the link-group as an aggregate, as I agree this is not useful. cheers, Peter > > Regards, > Richard > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On > > Behalf Of Peter Arberg > > Sent: 25 October 2005 22:07 > > To: 'David Ward'; 'Pekka Savola'; rtg-bfd@ietf.org; 'Jeffrey Haas' > > Subject: RE: document layout for singlehop, multihop and generic > > > > > > Hi, > > > > I have one suggestion which I would like to see in one of the > > documents, best fit would proabably be in the 1hop document, > > but could also be in the generic one. > > > > The usage of BFD over 802.3ad ethernet link-groups, in an > > application to detect faults in the individual links inside > > the link-group. > > > > (not BFD over ethernet, but using the BFD over UDP approach) > > > > I could propose some text for this, and we can discuss it > > based on this, and then if you do not think it belongs in either > > of these document, or it is to late in the game to propose > > changes, then I could create a new internet-draft with a > > suggestion for this functionality. > > > > thanks, > > Peter > > > > > -----Original Message----- > > > From: rtg-bfd-bounces@ietf.org > > > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of David Ward > > > Sent: 25. oktober 2005 22:46 > > > To: Pekka Savola; rtg-bfd@ietf.org; David Ward; Jeffrey Haas > > > Subject: Re: document layout for singlehop, multihop and generic > > > > > > We covered this at the last several WG meetings. The issue > > > is: reorganizing > > > the docs w/o changing the content vs getting the docs to spec > > > ... The WG > > > agreed to get the docs to full standard. > > > > > > -DWard > > > > > > > > > On 10/25/05 5:22 AM, "Pekka Savola" wrote: > > > > > > > Hi, > > > > > > > > I'm still puzzled by the coverage of various documents: > > > > > > > > 1) bfd-multihop-03: about 3 pages of very generic (non-protocol > > > > specific) guidance on multihop BFD sessions. > > > > > > > > 2) bfd-v4v6-1hop-04: the first 4.5 pages are very generic > > single-hop > > > > BGP guidance (applicable to any single hop BFD > > > application), the next > > > > 4 pages detail a number of OSPF/IS-IS details for > single-hop cases > > > > > > > > 3) bfd-generic-01: about 5 pages of generic BFD guidance (not > > > > specific to either single or multihop). > > > > > > > > This seems like patchwork. IMHO, a more logical > > separation might be > > > > having everything generic (either single or multihop) in > > > one document > > > > and moving the protocol-specific details out of v2v6-1hop to a > > > > separate BFD+OSPF/ISIS document. > > > > > > > > > > From rtg-bfd-bounces@ietf.org Fri Oct 28 01:35:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVMty-0004EK-NV; Fri, 28 Oct 2005 01:35:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVMtw-0004EF-BX for rtg-bfd@megatron.ietf.org; Fri, 28 Oct 2005 01:35:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22110 for ; Fri, 28 Oct 2005 01:35:23 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVN7R-0000le-PU for rtg-bfd@ietf.org; Fri, 28 Oct 2005 01:49:38 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9S5ZL715649; Fri, 28 Oct 2005 08:35:21 +0300 Date: Fri, 28 Oct 2005 08:35:21 +0300 (EEST) From: Pekka Savola To: David Ward In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rtg-bfd@ietf.org, Jeffrey Haas , Dave Katz Subject: Re: BFD w/ static routes and single-hop eBGP X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On Wed, 26 Oct 2005, David Ward wrote: [...] > This is stated already. A lot of things are stated already, in generic context. What I'd like to see is a brief, normative description how those apply to protocol Foo. If there's nothing to say (e.g., with static routes) one or two sentences may be enough; if there is little to say (e.g., eBGP), maybe a couple of paragraphs is enough. >> The third party nexthop case is the more interesting one. I believe >> you'd want a BFD session for each third party nexthop. >> > > I disagree here. The reason being ... What do you care about the > intermediate NHs wrt the EBGP bootstrapping since you can route to/through > different intermediate NH? [...] I agree with Dave here. BGP hello mechanism does not monitor the liveness of the 3rd party nexthops, and therefore I think it goes beyond the scope of BFD to do that, even though BFD is meant to detect forwarding problems (which obviously would happen if the 3rd party next-hop would go away). (It might not hurt as an extension, but we don't see a need for it.) -- 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 rtg-bfd-bounces@ietf.org Fri Oct 28 11:03:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVlN-0003Nc-BL; Fri, 28 Oct 2005 11:03:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVlM-0003NB-Ic for rtg-bfd@megatron.ietf.org; Fri, 28 Oct 2005 11:03:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22790 for ; Fri, 28 Oct 2005 11:03:08 -0400 (EDT) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVVyr-0008Vf-UN for rtg-bfd@ietf.org; Fri, 28 Oct 2005 11:17:27 -0400 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with SMTP id 854F712DA1F; Fri, 28 Oct 2005 15:00:05 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 245JJbo8j0155Mo1; Fri, 28 Oct 2005 14:59:36 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 047JJbo8Z0046Mo1; Fri, 28 Oct 2005 14:59:25 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.26F); Fri, 28 Oct 2005 14:59:25 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw2.EXCHPROD.USA.NET X-USANET-MsgId: XID409JJbo8A1256Xo1 Received: from localhost ([65.247.36.31]) by gw2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 08:59:25 -0600 Date: Fri, 28 Oct 2005 10:59:24 -0400 From: Jeffrey Haas To: Pekka Savola Message-ID: <20051028145924.GG18406@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 28 Oct 2005 14:59:25.0587 (UTC) FILETIME=[300E9630:01C5DBD0] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rtg-bfd@ietf.org, David Ward , Dave Katz Subject: Re: BFD w/ static routes and single-hop eBGP X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On Fri, Oct 28, 2005 at 08:35:21AM +0300, Pekka Savola wrote: > >>[Jeff] > >>The third party nexthop case is the more interesting one. I believe > >>you'd want a BFD session for each third party nexthop. > >> > >[Dave] > >I disagree here. The reason being ... What do you care about the > >intermediate NHs wrt the EBGP bootstrapping since you can route to/through > >different intermediate NH? [...] > > [Pekka] > I agree with Dave here. BGP hello mechanism does not monitor the > liveness of the 3rd party nexthops, and therefore I think it goes > beyond the scope of BFD to do that, even though BFD is meant to detect > forwarding problems (which obviously would happen if the 3rd party > next-hop would go away). BFD to monitor the liveness of the BGP peering session is good. In most eBGP cases, this is also sufficient to monitor the ability of the announced nexthop (usually the same as the address of the peering session) to forward traffic. In the case of third party nexthops, it isn't. To give an example that may have bitten some people in this working group, presume an exchange point where peering is done via eBGP. In the case that third party nexthops are permitted, you can announce a nexthop that would normally be considered reachable because you are on a shared subnet. If the nexthop is not reachable for some reason, but the peering session is up, a blackhole will occur. Solutions: - Disallow third party nexthops. - Run a BFD session on your nexthop. -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Fri Oct 28 11:58:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWci-0005lS-Ch; Fri, 28 Oct 2005 11:58:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWcg-0005lK-AI for rtg-bfd@megatron.ietf.org; Fri, 28 Oct 2005 11:58:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26026 for ; Fri, 28 Oct 2005 11:58:13 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVWqH-0001oZ-5j for rtg-bfd@ietf.org; Fri, 28 Oct 2005 12:12:33 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2005 08:58:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9SFwAJn029036; Fri, 28 Oct 2005 08:58:18 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 08:58:16 -0700 Received: from [171.71.139.74] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 08:58:15 -0700 User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Fri, 28 Oct 2005 10:58:28 -0500 From: David Ward To: Jeffrey Haas , Pekka Savola Message-ID: In-Reply-To: <20051028145924.GG18406@nexthop.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Oct 2005 15:58:16.0089 (UTC) FILETIME=[68667090:01C5DBD8] X-Spam-Score: 1.1 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, Dave Katz Subject: Re: BFD w/ static routes and single-hop eBGP X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Jeff - On 10/28/05 9:59 AM, "Jeffrey Haas" wrote: > On Fri, Oct 28, 2005 at 08:35:21AM +0300, Pekka Savola wrote: >>>> [Jeff] >>>> The third party nexthop case is the more interesting one. I believe >>>> you'd want a BFD session for each third party nexthop. >>>> >>> [Dave] >>> I disagree here. The reason being ... What do you care about the >>> intermediate NHs wrt the EBGP bootstrapping since you can route to/through >>> different intermediate NH? [...] >> >> [Pekka] >> I agree with Dave here. BGP hello mechanism does not monitor the >> liveness of the 3rd party nexthops, and therefore I think it goes >> beyond the scope of BFD to do that, even though BFD is meant to detect >> forwarding problems (which obviously would happen if the 3rd party >> next-hop would go away). > > BFD to monitor the liveness of the BGP peering session is good. No, it is bad :-) We state that you can attempt to use BFD for control plane liveness (you can do anything you want) but, BFD is for the control plane and we don't suggest that you use it for the control plane liveness at all. We suggest that control protocols Hello packets run sedate and instead, use BFD just for the forwarding plane. > In most eBGP cases, this is also sufficient to monitor the ability of > the announced nexthop (usually the same as the address of the peering > session) to forward traffic. > > In the case of third party nexthops, it isn't. > > To give an example that may have bitten some people in this working > group, presume an exchange point where peering is done via eBGP. > In the case that third party nexthops are permitted, you can announce > a nexthop that would normally be considered reachable because you are > on a shared subnet. If the nexthop is not reachable for some reason, > but the peering session is up, a blackhole will occur. > > Solutions: > - Disallow third party nexthops. > - Run a BFD session on your nexthop. Run a BFD session on the NH but, don't have it test the BGP session. Only the NH. Echo mode is wonderful for this :-) -DWard


A has sent normal bfd control pkt to B and immediately it = changes its Tx interval and therefore sends one more bfd control pkt = with POLL bit set n change of Min Tx interval.But B before = processing the POLL bit received pkt sends its normal bfd control pkt = for link detection.(therefore this packet will not have FIN = set)

Now A may conclude with the recived bfd normal control = packet which does not have FIN bit set as declined = parameter

I'm not sure what you mean by = "declined parameter," there is no such thing.=A0 Parameters in BFD are = not "negotiated" in the normal way;=A0 rather, each side announces its = timing parameters and the other side MUST obey them (and choose the = largest value of each pair, e.g. my TX and your = RX.)