From rtg-bfd-bounces@ietf.org Thu Aug 04 15:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ljE-0001r1-KQ; Thu, 04 Aug 2005 15:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0lj8-0001op-Os; Thu, 04 Aug 2005 15:50:02 -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 PAA04572; Thu, 4 Aug 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0mG5-0005UE-Ke; Thu, 04 Aug 2005 16:24:05 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E0lj7-0006FR-QV; Thu, 04 Aug 2005 15: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: Thu, 04 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-mib-02.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 Management Information Base Author(s) : T. Nadeau, Z. Ali Filename : draft-ietf-bfd-mib-02.txt Pages : 24 Date : 2005-8-4 This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol [BFD]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-02.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-mib-02.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-mib-02.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-8-4143151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-4143151.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Thu Aug 04 23:52:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0tFn-0006Yd-1R; Thu, 04 Aug 2005 23:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0tFl-0006YU-TG for rtg-bfd@megatron.ietf.org; Thu, 04 Aug 2005 23:52:13 -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 XAA28055 for ; Thu, 4 Aug 2005 23:52:11 -0400 (EDT) Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0tml-0000P8-OU for rtg-bfd@ietf.org; Fri, 05 Aug 2005 00:26:21 -0400 Content-Class: urn:content-classes:message X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Aug 2005 09:22:01 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Aug 2005 09:22:01 +0530 Message-ID: <15226CC274ADF842929EEAB80EB965F0CF3DA7@kavithai.ctd.hcltech.com> From: "Sankaranarayanan - CTD, Chennai." Content-Transfer-Encoding: quoted-printable To: Date: Fri, 5 Aug 2005 09:22:00 +0530 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Aug 2005 03:52:01.0281 (UTC) FILETIME=[09176710:01C59971] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Subject: Session state notifications 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 Hello, Description of bfdSessDiag says "A diagnostic code specifying the local system's reason for the last transition of the session from up(1) to some other state." But the description of bfdSessUp notification says that value up (1) is set to bfdSessDiag and description of bfdSessDown notification says that value down (4) or adminDown (5)is set to bfdSessDiag. I am not sure whether bfdSessDiag object in the notification is used to communicate the diagnostic code or session state. As per the new standard bfdSessState uses value 4 for up state. But description of bfdSessDiag uses value 1 and description of bfdSessUp notification uses value 1 and 2 for up state. Similarly bfdSessState uses value 1 for adminDown and value 2 for down state. But description of bfdSessDown notification uses value 5 for adminDown state and value 4 for down state. =20 Regards, Sankar DISCLAIMER=20 This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies=20 and its customers. Contents may be privileged or otherwise protected by = law. The information is solely intended for the=20 individual or the entity it is addressed to. If you are not the intended = recipient of this message, you are not authorized to=20 read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error,=20 please notify the sender immediately by return e-mail and delete it from = your computer From rtg-bfd-bounces@ietf.org Fri Aug 05 01:37:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0utN-0001Qg-1i; Fri, 05 Aug 2005 01:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0utL-0001Qb-5j for rtg-bfd@megatron.ietf.org; Fri, 05 Aug 2005 01:37:11 -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 BAA02015 for ; Fri, 5 Aug 2005 01:37:10 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0vQM-0002QX-9n for rtg-bfd@ietf.org; Fri, 05 Aug 2005 02:11:19 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j755ad976380; Thu, 4 Aug 2005 22:36:49 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j755aYG54702; Thu, 4 Aug 2005 22:36:34 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <15226CC274ADF842929EEAB80EB965F0CF3DA7@kavithai.ctd.hcltech.com> References: <15226CC274ADF842929EEAB80EB965F0CF3DA7@kavithai.ctd.hcltech.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <859C7F10-EEDD-4A49-A667-DCC1E8C280C0@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 4 Aug 2005 22:36:33 -0700 To: "Sankaranarayanan - CTD, Chennai." X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Session state notifications 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 Aug 4, 2005, at 8:52 PM, Sankaranarayanan - CTD, Chennai. wrote: > > Hello, > > > Description of bfdSessDiag says "A diagnostic code > specifying the local system's reason for the last > transition of the session from up(1) to some other > state. Which document are you referring to? The base spec says: A diagnostic code specifying the local system's reason for the last session state change. In any case, the diagnostic is just that, a diagnostic, generally intended to make life easier for network operators to figure out what went wrong. This is entirely separate from the session state, which is an integral part of the state machine. From rtg-bfd-bounces@ietf.org Fri Aug 05 04:46:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xqf-0006w5-VT; Fri, 05 Aug 2005 04:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xqe-0006w0-F8 for rtg-bfd@megatron.ietf.org; Fri, 05 Aug 2005 04:46:36 -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 EAA26649 for ; Fri, 5 Aug 2005 04:46:34 -0400 (EDT) Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0yNg-0008Ou-V5 for rtg-bfd@ietf.org; Fri, 05 Aug 2005 05:20:46 -0400 Content-Class: urn:content-classes:message X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Aug 2005 14:16:23 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Aug 2005 14:16:23 +0530 Message-ID: <15226CC274ADF842929EEAB80EB965F0D0A7FF@kavithai.ctd.hcltech.com> From: "Sankaranarayanan - CTD, Chennai." To: "Dave Katz" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Aug 2005 14:16:22 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Aug 2005 08:46:23.0402 (UTC) FILETIME=[288930A0:01C5999A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org Subject: RE: Session state notifications 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 Hello Dave, I referred to the description of bfdSessDiag objects and bfdSessUp and bfdSessDown notification in the MIB. Regards, Sankar -----Original Message----- From: Dave Katz [mailto:dkatz@juniper.net] Sent: Friday, August 05, 2005 11:07 AM To: Sankaranarayanan - CTD, Chennai. Cc: rtg-bfd@ietf.org Subject: Re: Session state notifications On Aug 4, 2005, at 8:52 PM, Sankaranarayanan - CTD, Chennai. wrote: > > Hello, > > > Description of bfdSessDiag says "A diagnostic code > specifying the local system's reason for the last > transition of the session from up(1) to some other > state. Which document are you referring to? The base spec says: A diagnostic code specifying the local system's reason for the =20 last session state change. In any case, the diagnostic is just that, a diagnostic, generally =20 intended to make life easier for network operators to figure out what =20 went wrong. This is entirely separate from the session state, which is an =20 integral part of the state machine. DISCLAIMER=20 This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies=20 and its customers. Contents may be privileged or otherwise protected by = law. The information is solely intended for the=20 individual or the entity it is addressed to. If you are not the intended = recipient of this message, you are not authorized to=20 read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error,=20 please notify the sender immediately by return e-mail and delete it from = your computer From rtg-bfd-bounces@ietf.org Fri Aug 05 12:32:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E157g-0001e9-6d; Fri, 05 Aug 2005 12:32:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E157d-0001ag-FT for rtg-bfd@megatron.ietf.org; Fri, 05 Aug 2005 12:32: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 MAA19093 for ; Fri, 5 Aug 2005 12:32:34 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E15el-0003kn-9B for rtg-bfd@ietf.org; Fri, 05 Aug 2005 13:06:51 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j75GWMBm036258; Fri, 5 Aug 2005 09:32:22 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j75GWMG50997; Fri, 5 Aug 2005 09:32:22 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <15226CC274ADF842929EEAB80EB965F0D0A7FF@kavithai.ctd.hcltech.com> References: <15226CC274ADF842929EEAB80EB965F0D0A7FF@kavithai.ctd.hcltech.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42F2F858-6CD1-4E87-A6B4-8743221DC1DB@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Fri, 5 Aug 2005 09:32:21 -0700 To: "Sankaranarayanan - CTD, Chennai." X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Session state notifications 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 Ah, that explains it. There's enough documents floating around that it helps to be specific. You're right, there does seem to be some confusion in the MIB document. I'll post a separate email with comments on the MIB. --Dave On Aug 5, 2005, at 1:46 AM, Sankaranarayanan - CTD, Chennai. wrote: > Hello Dave, > > I referred to the description of bfdSessDiag objects > and bfdSessUp and bfdSessDown notification in the MIB. > > Regards, > Sankar > > > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Friday, August 05, 2005 11:07 AM > To: Sankaranarayanan - CTD, Chennai. > Cc: rtg-bfd@ietf.org > Subject: Re: Session state notifications > > > > On Aug 4, 2005, at 8:52 PM, Sankaranarayanan - CTD, Chennai. wrote: > > >> >> Hello, >> >> >> Description of bfdSessDiag says "A diagnostic code >> specifying the local system's reason for the last >> transition of the session from up(1) to some other >> state. >> > > Which document are you referring to? The base spec says: > > A diagnostic code specifying the local system's reason for the > last session state change. > > In any case, the diagnostic is just that, a diagnostic, generally > intended to make life easier for network operators to figure out what > went wrong. > > This is entirely separate from the session state, which is an > integral part of the state machine. > DISCLAIMER > This message and any attachment(s) contained here are information > that is confidential, proprietary to HCL Technologies > and its customers. Contents may be privileged or otherwise > protected by law. The information is solely intended for the > individual or the entity it is addressed to. If you are not the > intended recipient of this message, you are not authorized to > read, forward, print, retain, copy or disseminate this message or > any part of it. If you have received this e-mail in error, > please notify the sender immediately by return e-mail and delete it > from your computer > > > From rtg-bfd-bounces@ietf.org Fri Aug 05 12:53:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E15S8-0006HV-1N; Fri, 05 Aug 2005 12:53:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E15S6-0006HQ-7B for rtg-bfd@megatron.ietf.org; Fri, 05 Aug 2005 12:53: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 MAA20141 for ; Fri, 5 Aug 2005 12:53:43 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E15zD-0004RL-3t for rtg-bfd@ietf.org; Fri, 05 Aug 2005 13:28:00 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j75GrZ981655 for ; Fri, 5 Aug 2005 09:53:35 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j75GrUG54236 for ; Fri, 5 Aug 2005 09:53:30 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: <27F4588E-E478-4A94-95EB-0624FC065657@juniper.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "'rtg-bfd@ietf.org'" From: Dave Katz Date: Fri, 5 Aug 2005 09:53:29 -0700 X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: Comments on draft-ietf-bfd-mib-02.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 MIBs make my head spin, but I noticed a few things based on comments from Sankar. These comments may be wildly off the mark, as I don't really grok MIBs (an arcane art to be sure), but not knowing what I was talking about has never stopped me in the past. First, the document reference is incorrect; it refers to Version 0 and the 02 base spec, but the 02 base spec was Version 1 of the protocol (and the current draft is 03, though that shouldn't have any effect on the MIB as far as I can tell.) There is major confusion over the session state; I'm guessing that earlier versions of the MIB had a locally defined session state variable, but when the session state became codified in the protocol the state values all changed. There are numerous references of the form "up(1)" (and "up(2)" for that matter) for all session state values that are incorrect and in some cases contradictory. The bfdSessUp and bfdSessDown notifications should presumably have parameters of type bfdSessIndex. The comments under them I don't understand at all (and were the source of Sankar's concern.) I'm guessing that the sentence "The included values of bfdSessDiag MUST both be set equal to this new state" is trying to say that all of the sessions indicated by the index range must both be in Up state (which has nothing to do with the diagnostic value), but I'm not sure what the point of that is (and if the session entries are subsequently grabbed from the MIB, there is a very good chance that the sessions will *not* be in the specified state, as the notification will be stale.) In a related area, BfdDiag defines the diagnostic values, but bfdSessDiag is defined as an opaque 32 bit value. Shouldn't the latter be defined in terms of the former? The comment for bfdSessDiag is too restrictive, as the session diagnostic has gotten a bit more flexible as the base spec progressed. The diagnostic is sometimes set in situations other than a transition away from Up state. --Dave From rtg-bfd-bounces@ietf.org Fri Aug 05 16:33:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18si-00069Q-W1; Fri, 05 Aug 2005 16:33:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18sh-00069H-8Y for rtg-bfd@megatron.ietf.org; Fri, 05 Aug 2005 16:33: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 QAA02508 for ; Fri, 5 Aug 2005 16:33:24 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E19Pq-0002g8-9L for rtg-bfd@ietf.org; Fri, 05 Aug 2005 17:07:43 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 05 Aug 2005 13:33:19 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,171,1120460400"; d="scan'208"; a="4894280:sNHT22191320" Received: from [10.83.15.52] (rtp-tnadeau-vpn3.cisco.com [10.83.15.52]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j75KXEQm004019; Fri, 5 Aug 2005 16:33:15 -0400 (EDT) In-Reply-To: <27F4588E-E478-4A94-95EB-0624FC065657@juniper.net> References: <27F4588E-E478-4A94-95EB-0624FC065657@juniper.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21A12C12-2C59-427B-857F-1846A1DF411B@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Fri, 5 Aug 2005 16:33:08 -0400 To: Dave Katz X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, Zafar Ali Subject: Re: Comments on draft-ietf-bfd-mib-02.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 > MIBs make my head spin, but I noticed a few things based on > comments from Sankar. These comments may be wildly off the mark, > as I don't really grok MIBs (an arcane art to be sure), Oh, its part of the Dark Arts (see Harry Potter) for sure. *) > but not knowing what I was talking about has never stopped me in > the past. > > > First, the document reference is incorrect; it refers to Version 0 > and the 02 base spec, but the 02 base spec was Version 1 of the > protocol (and the current draft is 03, though that shouldn't have > any effect on the MIB as far as I can tell.) I published an -02 version yesterday before leaving for home which does update the references, and straightened out a few nits related to compliance with http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- guidelines-04.txt > There is major confusion over the session state; I'm guessing that > earlier versions of the MIB had a locally defined session state > variable, but when the session state became codified in the > protocol the state values all changed. There are numerous > references of the form "up(1)" (and "up(2)" for that matter) for > all session state values that are incorrect and in some cases > contradictory. Will fix. > The bfdSessUp and bfdSessDown notifications should presumably have > parameters of type bfdSessIndex. A little MIB voodoo here. We included the bfdSessDiag variable, which does indeed include the bfdSessIndex as part of its OID that will be generated when the notification is generated by the agent. It is actually bad practice to include the indexes explicitly within a notification for this very reason (its already part of the variables included therein). > The comments under them I don't understand at all (and were the > source of Sankar's concern.) I'm guessing that the sentence "The > included values of bfdSessDiag MUST both be set equal to this new > state" is trying to say that all of the sessions indicated by the > index range must both be in Up state (which has nothing to do with > the diagnostic value), but I'm not sure what the point of that is The point of having both variables is to indeed indicate a hi/lo range of the same type of notification for a set of contiguous sessions if your implementation can handle this, otherwise you an just generate one for each session and keep both variables equal. The choice of the bfdSessDiag variable was simply to include additional information beyond indicating which session was going up or down. If you or others feel that we should include another value(s), then let us know. > (and if the session entries are subsequently grabbed from the MIB, > there is a very good chance that the sessions will *not* be in the > specified state, as the notification will be stale.) That is okay. Their INDEX will remain, and so their actual state can be examined. The idea of the notification was to indicate that a state had transitioned from the steady state to something else, possibly indicating a failure/mis-config to an operator. > In a related area, BfdDiag defines the diagnostic values, but > bfdSessDiag is defined as an opaque 32 bit value. Shouldn't the > latter be defined in terms of the former? Yes, the MIB value needs to be adjusted to accurately reflect the latest draft. > The comment for bfdSessDiag is too restrictive, as the session > diagnostic has gotten a bit more flexible as the base spec > progressed. The diagnostic is sometimes set in situations other > than a transition away from Up state. OK, will adjust. If you have any suggested text, please send it our way. --Tom > > --Dave > From rtg-bfd-bounces@ietf.org Mon Aug 08 14:43:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2CbJ-0007lB-Ej; Mon, 08 Aug 2005 14:43:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2CbI-0007kq-6G for rtg-bfd@megatron.ietf.org; Mon, 08 Aug 2005 14:43:52 -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 OAA08494 for ; Mon, 8 Aug 2005 14:43:50 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2D91-0008O7-MC for rtg-bfd@ietf.org; Mon, 08 Aug 2005 15:18:44 -0400 Received: from pc6 (1Cust172.tnt4.lnd4.gbr.da.uu.net [62.188.133.172]) by ranger.systems.pipex.net (Postfix) with SMTP id B5AF5E0001AB; Mon, 8 Aug 2005 19:43:30 +0100 (BST) Message-ID: <00a301c59c40$857e15c0$0601a8c0@pc6> From: "Tom Petch" To: "Thomas D. Nadeau" References: <27F4588E-E478-4A94-95EB-0624FC065657@juniper.net> <21A12C12-2C59-427B-857F-1846A1DF411B@cisco.com> Date: Mon, 8 Aug 2005 15:40:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.8 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, Zafar Ali Subject: Re: Comments on draft-ietf-bfd-mib-02.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch 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 Looking at BfdDiag Textual Convention, I wonder if there is a better way of doing this. I suspect that this is a list of diagnostic values that will evolve faster than the rest of the MIB module so rather than updating the RFC every time, or letting it get out of date, you could extract the Textual Convention from the normative part of the MIB and put it under IANA control with whatever rules you consider suitable for updating it. This approach has been sucessfully adopted by disman with Alarm MIB (RFC3877 s.5), inter alia. Tom Petch From rtg-bfd-bounces@ietf.org Mon Aug 08 16:01:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Dol-0007Sk-4e; Mon, 08 Aug 2005 16:01:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Doj-0007OF-GZ for rtg-bfd@megatron.ietf.org; Mon, 08 Aug 2005 16:01:49 -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 QAA15761 for ; Mon, 8 Aug 2005 16:01:47 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2EMR-0002zG-Ik for rtg-bfd@ietf.org; Mon, 08 Aug 2005 16:36:43 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 08 Aug 2005 13:01:37 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,89,1122879600"; d="scan'208"; a="5152263:sNHT20703320" Received: from [161.44.71.222] ([161.44.71.222]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j78K1XT6017130; Mon, 8 Aug 2005 16:01:33 -0400 (EDT) In-Reply-To: <00a301c59c40$857e15c0$0601a8c0@pc6> References: <27F4588E-E478-4A94-95EB-0624FC065657@juniper.net> <21A12C12-2C59-427B-857F-1846A1DF411B@cisco.com> <00a301c59c40$857e15c0$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68BD4818-1602-4FE6-AE1A-6AF1684D973A@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Mon, 8 Aug 2005 16:01:28 -0400 To: "Tom Petch" X-Mailer: Apple Mail (2.733) X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [161.44.71.222] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, Zafar Ali Subject: Re: Comments on draft-ietf-bfd-mib-02.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 This is along the lines of what Katz was suggesting earlier WRT updating the diag section. I like the IANA control idea. --Tom > Looking at BfdDiag Textual Convention, I wonder if there is a > better way of > doing this. I suspect that this is a list of diagnostic values > that will evolve > faster than the rest of the MIB module so rather than updating the > RFC every > time, or letting it get out of date, you could extract the Textual > Convention > from the normative part of the MIB and put it under IANA control > with whatever > rules you consider suitable for updating it. > > This approach has been sucessfully adopted by disman with Alarm MIB > (RFC3877 > s.5), inter alia. > > Tom Petch > From rtg-bfd-bounces@ietf.org Wed Aug 10 16:17:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2x0s-0001s4-4l; Wed, 10 Aug 2005 16:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2x0q-0001rY-AE for rtg-bfd@megatron.ietf.org; Wed, 10 Aug 2005 16:17:20 -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 QAA01166 for ; Wed, 10 Aug 2005 16:17:17 -0400 (EDT) Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2xYz-0004hM-Ln for rtg-bfd@ietf.org; Wed, 10 Aug 2005 16:52:39 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 4BF6F163D7D for ; Wed, 10 Aug 2005 20:16:54 +0000 (GMT) Received: from gateout02.mbox.net [165.212.64.22] by gateout02.mbox.net via mtad (C8.MAIN.3.17K) with ESMTP id 577JHJuq30185Mo2; Wed, 10 Aug 2005 20:16:53 GMT Received: from gw1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Wed, 10 Aug 2005 20:16:53 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw1.EXCHPROD.USA.NET X-USANET-MsgId: XID162JHJuq33078Xo2 Received: from localhost ([65.247.36.31]) by gw1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 14:16:53 -0600 Date: Wed, 10 Aug 2005 16:16:52 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Message-ID: <20050810201652.GS5530@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 10 Aug 2005 20:16:53.0579 (UTC) FILETIME=[72E941B0:01C59DE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: MIB question - default BFD enable status? 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 Since I'm now freed from the tyrannies of my company's latest release, I'm in the process of reviewing the various BFD specificiations. One of the questions that came up in during the MIB review was something that input from the WG would be helpful for: bfdAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The global administrative status of BFD in this router. The value 'enabled' denotes that the BFD Process is active on at least one interface; 'disabled' disables it on all interfaces." DEFVAL { enabled } ::= { bfdScalarObjects 1 } Arguments can be made both ways for this feature to be enabled or disabled by default. I believe that, at least in the MIB, it should be disabled. If you have an opinion, please bring it to the list. -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Thu Aug 11 01:01:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35CX-0003Sh-OH; Thu, 11 Aug 2005 01:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35CU-0003SS-F1 for rtg-bfd@megatron.ietf.org; Thu, 11 Aug 2005 01:01:55 -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 BAA24194 for ; Thu, 11 Aug 2005 01:01:53 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E35kj-0008V6-KL for rtg-bfd@ietf.org; Thu, 11 Aug 2005 01:37:18 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7B4vNP25716; Thu, 11 Aug 2005 07:57:32 +0300 Date: Thu, 11 Aug 2005 07:57:23 +0300 (EEST) From: Pekka Savola To: Jeffrey Haas In-Reply-To: <20050810201652.GS5530@nexthop.com> Message-ID: References: <20050810201652.GS5530@nexthop.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rtg-bfd@ietf.org Subject: Re: MIB question - default BFD enable status? 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, 10 Aug 2005, Jeffrey Haas wrote: > Since I'm now freed from the tyrannies of my company's latest release, I'm > in the process of reviewing the various BFD specificiations. One > of the questions that came up in during the MIB review was something > that input from the WG would be helpful for: > > bfdAdminStatus OBJECT-TYPE > SYNTAX INTEGER { enabled(1), disabled(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The global administrative status of BFD in this router. > The value 'enabled' denotes that the BFD Process is > active on at least one interface; 'disabled' disables > it on all interfaces." > DEFVAL { enabled } > ::= { bfdScalarObjects 1 } > > Arguments can be made both ways for this feature to be enabled or disabled > by default. I believe that, at least in the MIB, it should be disabled. First off, is there usefulness in creating a read-write mib in the first place? But even if we do, I don't think this global feature is even needed -- isn't it enough to have interface, protocol, or other status values which the operators can then snmpwalk through ? -- 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 Thu Aug 11 15:49:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3J3Z-0005Mv-Bp; Thu, 11 Aug 2005 15:49:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3J3W-0005Mq-Uo for rtg-bfd@megatron.ietf.org; Thu, 11 Aug 2005 15:49:36 -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 PAA24115 for ; Thu, 11 Aug 2005 15:49:33 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Jbs-00073F-Ut for rtg-bfd@ietf.org; Thu, 11 Aug 2005 16:25:06 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2005 12:49:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,100,1122879600"; d="scan'208"; a="5655744:sNHT22663396" Received: from [10.83.15.53] (rtp-tnadeau-vpn4.cisco.com [10.83.15.53]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j7BJnJT7018212; Thu, 11 Aug 2005 15:49:20 -0400 (EDT) In-Reply-To: References: <20050810201652.GS5530@nexthop.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31E8370C-8A00-4451-AB12-73B1A696CC58@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Thu, 11 Aug 2005 15:49:12 -0400 To: Pekka Savola X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, Jeffrey Haas Subject: Re: MIB question - default BFD enable status? 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 Aug 11, 2005, at 12:57 AM, Pekka Savola wrote: > On Wed, 10 Aug 2005, Jeffrey Haas wrote: > >> Since I'm now freed from the tyrannies of my company's latest >> release, I'm >> in the process of reviewing the various BFD specificiations. One >> of the questions that came up in during the MIB review was something >> that input from the WG would be helpful for: >> >> bfdAdminStatus OBJECT-TYPE >> SYNTAX INTEGER { enabled(1), disabled(2) } >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "The global administrative status of BFD in this router. >> The value 'enabled' denotes that the BFD Process is >> active on at least one interface; 'disabled' disables >> it on all interfaces." >> DEFVAL { enabled } >> ::= { bfdScalarObjects 1 } >> >> Arguments can be made both ways for this feature to be enabled or >> disabled >> by default. I believe that, at least in the MIB, it should be >> disabled. >> > > First off, is there usefulness in creating a read-write mib in the > first place? This is a great point, and one which I was hoping to raise (it was one of Jeff's review comments). I personally think that r-o is fine. > But even if we do, I don't think this global feature is even needed > -- isn't it enough to have interface, protocol, or other status > values which the operators can then snmpwalk through ? I know of at least one implementation that has BFD as a global configuration. --Tom > > -- > 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 Thu Aug 11 16:58:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3K8X-0002fo-GG; Thu, 11 Aug 2005 16:58:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3K8R-0002fc-MV for rtg-bfd@megatron.ietf.org; Thu, 11 Aug 2005 16:58:47 -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 QAA27204 for ; Thu, 11 Aug 2005 16:58:41 -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 1E3Kgo-0000Dj-EE for rtg-bfd@ietf.org; Thu, 11 Aug 2005 17:34:16 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2005 13:58:32 -0700 X-IronPort-AV: i="3.96,100,1122879600"; d="scan'208,217"; a="331423825:sNHT50068542" 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 j7BKwSoq003560 for ; Thu, 11 Aug 2005 13:58:30 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 13:58:28 -0700 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_01C59EB7.6C39BDC5" Date: Thu, 11 Aug 2005 13:58:27 -0700 Message-ID: Thread-Topic: Echo Function and Asymmetry - Timer negotiation Thread-Index: AcWet2u3Jl2hKs6hQBidAQ4LNHIcWg== From: "Tanya Shastri \(tanyas\)" To: X-OriginalArrivalTime: 11 Aug 2005 20:58:28.0306 (UTC) FILETIME=[6C4C2320:01C59EB7] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: Echo Function and Asymmetry - Timer negotiation 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_01C59EB7.6C39BDC5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 For an Asynchronous BFD session that has Asymmetric Echo function the following statements in the spec seem to be misleading, unless I am missing something. =20 Section 6.4 says: "When a system is using the Echo function, it is advantageous to choose a sedate transmission rate for Control packets since liveness detection is being handled by the Echo packets." Shouldn't it be the receive rate - or the transmission rate of Control packets of the remote system - that should be sedate? Also the end that does not have echo mode active relies on Control packets for liveness detection and may still want to receive Control packets at a faster rate. =20 Section 6.7.3 says: " When the Echo function is active, a system SHOULD set bfd.DesiredMinTxInterval to a value of not less than one second" >From the description in 6.7.4 this will force the remote end to have a Detect Timer no faster than 1 second, since the Detect Timer is based on the transmit rate of the remote system. Also this will not reduce the rate at which it sends control packets to the end that has echo mode active. =20 Wouldn't it be better to suggest that "RequiredMinRxInterval" in BFD control packets should be set to a minimum of 1 second by the end that has echo function active? =20 Thanks, Tanya =20 =20 ------_=_NextPart_001_01C59EB7.6C39BDC5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
For an Asynchronous BFD session = that has=20 Asymmetric Echo function the following statements in the spec seem = to=20 be misleading, unless I am missing something.
 
Section 6.4 says: "When = a system=20 is using the Echo function, it is advantageous to choose a sedate = transmission=20 rate for Control packets since liveness detection = is being=20 handled by the Echo packets."
Shouldn't it be the receive rate - = or the=20 transmission rate of Control packets of the remote system - that should = be=20 sedate? Also the end that does not have echo mode active relies on = Control=20 packets for liveness detection and may still want to receive Control = packets at=20 a faster rate.
 
Section 6.7.3=20 says: " When the Echo function is active, a system = SHOULD=20 set bfd.DesiredMinTxInterval to a value of not less than one=20 second"
From the description in 6.7.4 this = will=20 force the remote end to have a Detect Timer no faster than 1 second, = since the=20 Detect Timer is based on the transmit rate of the remote system. Also=20 this will not reduce the rate at which it sends control packets to = the end=20 that has echo mode active.
 
Wouldn't it be better to = suggest=20 that "RequiredMinRxInterval" in BFD control = packets should be set=20 to a minimum of 1 second = by the end that has echo function = active?
 
Thanks,
Tanya
 
 
= ------_=_NextPart_001_01C59EB7.6C39BDC5-- From rtg-bfd-bounces@ietf.org Thu Aug 11 17:52:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3KyQ-0005jG-T4; Thu, 11 Aug 2005 17:52:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3KyO-0005j5-KF for rtg-bfd@megatron.ietf.org; Thu, 11 Aug 2005 17:52: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 RAA00038 for ; Thu, 11 Aug 2005 17:52:21 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3LWm-0001jH-2u for rtg-bfd@ietf.org; Thu, 11 Aug 2005 18:27:56 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7BLq8Bm011213; Thu, 11 Aug 2005 14:52:08 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7BLq8G28535; Thu, 11 Aug 2005 14:52:08 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: multipart/alternative; boundary=Apple-Mail-2--538957553 Message-Id: <5C78DA20-7FFA-41BB-BBC7-54B165751EDD@juniper.net> From: Dave Katz Date: Thu, 11 Aug 2005 14:52:10 -0700 To: Tanya Shastri ((tanyas)) X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.8 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: rtg-bfd@ietf.org Subject: Re: Echo Function and Asymmetry - Timer negotiation 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--538957553 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Aug 11, 2005, at 1:58 PM, Tanya Shastri ((tanyas)) wrote: > > For an Asynchronous BFD session that has Asymmetric Echo function > the following statements in the spec seem to be misleading, unless > I am missing something. > > Section 6.4 says: "When a system is using the Echo function, it is > advantageous to choose a sedate transmission rate for Control > packets since liveness detection is being handled by the Echo > packets." > Shouldn't it be the receive rate - or the transmission rate of > Control packets of the remote system - that should be sedate? Also > the end that does not have echo mode active relies on Control > packets for liveness detection and may still want to receive > Control packets at a faster rate. Yes, the language is a little slippery. It dates from a time in BFD prehistory when echo mode had to be symmetric, and the use of "transmission rate" was meant to be generic, that is, the packet rate. As you note, in the asymmetric case, the guy not running echo mode may like to be receiving control packets at a faster rate. > > Section 6.7.3 says: " When the Echo function is active, a system > SHOULD set bfd.DesiredMinTxInterval to a value of not less than one > second" > From the description in 6.7.4 this will force the remote end to > have a Detect Timer no faster than 1 second, since the Detect Timer > is based on the transmit rate of the remote system. Also this will > not reduce the rate at which it sends control packets to the end > that has echo mode active. > > Wouldn't it be better to suggest that "RequiredMinRxInterval" in > BFD control packets should be set to a minimum of 1 second by the > end that has echo function active? Same issue, but you're right. I'll fix it in the next round. --Dave --Apple-Mail-2--538957553 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Aug 11, 2005, = at 1:58 PM, Tanya Shastri ((tanyas)) wrote:

=
=A0
For an Asynchronous BFD session that has = Asymmetric Echo function=A0the following statements in the spec seem to = be=A0misleading, unless I am missing something.
=A0
=
Section 6.4 says: "When a system is using = the Echo function, it is advantageous to choose a sedate transmission = rate for Control packets since liveness detection is being handled by = the Echo packets."
Shouldn't it be the receive rate - or the = transmission rate of Control packets of the remote system - that should = be sedate? Also the end that does not have echo mode active relies on = Control packets for liveness detection and may still want to receive = Control packets at a faster = rate.

Yes, the language is a little = slippery.=A0 It dates from a time in BFD prehistory when echo mode had = to be symmetric, and the use of "transmission rate" was meant to be = generic, that is, the packet rate.=A0 As you note, in the asymmetric = case, the guy not running echo mode may like to be receiving control = packets at a faster rate.

=A0
Section = 6.7.3 says: " When the Echo function is active, a system SHOULD set = bfd.DesiredMinTxInterval to a value of not less than one = second"
=46rom the description in 6.7.4 this will = force the remote end to have a Detect Timer no faster than 1 second, = since the Detect Timer is based on the transmit rate of the remote = system. Also this=A0will not reduce the rate at which it sends control = packets to the end that has echo mode active.
=A0
Wouldn't it be=A0better=A0to suggest = that=A0"RequiredMinRxInterval"=A0in BFD control packets=A0should be set = to a minimum of 1=A0second = by the end that has echo = function active?

Same issue, but = you're right.=A0 I'll fix it in the next round.

--Dave

= --Apple-Mail-2--538957553-- From rtg-bfd-bounces@ietf.org Thu Aug 11 20:50:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Nkx-0001cg-Av; Thu, 11 Aug 2005 20:50:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Nkw-0001cb-FT for rtg-bfd@megatron.ietf.org; Thu, 11 Aug 2005 20:50: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 UAA09355 for ; Thu, 11 Aug 2005 20:50:41 -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 1E3OJJ-0006xC-VJ for rtg-bfd@ietf.org; Thu, 11 Aug 2005 21:26:16 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2005 17:50:30 -0700 X-IronPort-AV: i="3.96,101,1122879600"; d="scan'208"; a="331506186:sNHT30529336" 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 j7C0oM0L002937; Thu, 11 Aug 2005 17:50:26 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 20:50:25 -0400 Received: from [192.168.1.102] ([10.86.240.185]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 20:50:24 -0400 Message-ID: <42FBF24F.3070909@cisco.com> Date: Thu, 11 Aug 2005 20:50:23 -0400 From: Reshad Rahman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Katz References: <5C78DA20-7FFA-41BB-BBC7-54B165751EDD@juniper.net> In-Reply-To: <5C78DA20-7FFA-41BB-BBC7-54B165751EDD@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Aug 2005 00:50:24.0818 (UTC) FILETIME=[D32F5920:01C59ED7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Echo Function and Asymmetry - Timer negotiation 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 Dave Katz wrote: > > On Aug 11, 2005, at 1:58 PM, Tanya Shastri ((tanyas)) wrote: > >> >> For an Asynchronous BFD session that has Asymmetric Echo function the >> following statements in the spec seem to be misleading, unless I am >> missing something. >> >> Section 6.4 says: "When a system is using the Echo function, it is >> advantageous to choose a sedate transmission rate for Control packets >> since liveness detection is being handled by the Echo packets." >> Shouldn't it be the receive rate - or the transmission rate of >> Control packets of the remote system - that should be sedate? Also >> the end that does not have echo mode active relies on Control packets >> for liveness detection and may still want to receive Control packets >> at a faster rate. > > > Yes, the language is a little slippery. It dates from a time in BFD > prehistory when echo mode had to be symmetric, and the use of > "transmission rate" was meant to be generic, that is, the packet > rate. As you note, in the asymmetric case, the guy not running echo > mode may like to be receiving control packets at a faster rate. > It's not clear to me what's the benefit of doing this if the asymmetric echo is being run at fast rate. Failure in any direction will be detected by the asymmetric echo and the other end (which isn't running echo) will be notified on echo failure. So it's not clear to me what's the benefit of the the guy not running echo to be receiving control packets at a faster rate. It would seem that with asymmetric echo we can still run control packets at a sedate rate in both directions. Or am I missing something? Regards, Reshad. >> >> Section 6.7.3 says: " When the Echo function is active, a system >> SHOULD set bfd.DesiredMinTxInterval to a value of not less than one >> second" >> From the description in 6.7.4 this will force the remote end to have >> a Detect Timer no faster than 1 second, since the Detect Timer is >> based on the transmit rate of the remote system. Also this will not >> reduce the rate at which it sends control packets to the end that has >> echo mode active. >> >> Wouldn't it be better to suggest that "RequiredMinRxInterval" in BFD >> control packets should be set to a minimum of 1 second by the end >> that has echo function active? > > > Same issue, but you're right. I'll fix it in the next round. > > --Dave > From rtg-bfd-bounces@ietf.org Fri Aug 12 00:55:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3RZv-00014T-UG; Fri, 12 Aug 2005 00:55:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3RZq-00014O-CO for rtg-bfd@megatron.ietf.org; Fri, 12 Aug 2005 00:55: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 AAA18572 for ; Fri, 12 Aug 2005 00:55:27 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3S8H-0004Rt-C4 for rtg-bfd@ietf.org; Fri, 12 Aug 2005 01:31:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7C4sxp20897; Fri, 12 Aug 2005 07:54:59 +0300 Date: Fri, 12 Aug 2005 07:54:59 +0300 (EEST) From: Pekka Savola To: "Thomas D. Nadeau" In-Reply-To: <31E8370C-8A00-4451-AB12-73B1A696CC58@cisco.com> Message-ID: References: <20050810201652.GS5530@nexthop.com> <31E8370C-8A00-4451-AB12-73B1A696CC58@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rtg-bfd@ietf.org, Jeffrey Haas Subject: Re: MIB question - default BFD enable status? 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 Thu, 11 Aug 2005, Thomas D. Nadeau wrote: >> But even if we do, I don't think this global feature is even needed -- >> isn't it enough to have interface, protocol, or other status values which >> the operators can then snmpwalk through ? > > I know of at least one implementation that has BFD as a global > configuration. Let's take an analogue. Does the same implementation have a global configuration to enable/disable BGP? BGP and BFD sessions seem like similar beasts, and similar management techniques apply. I can only see (real) usefulness for session-based controls (and "enable BGP/BFD" toggle without session-specific config is quite questionable), but others might have different requirements so this isn't really a big issue to get too excited about. -- 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 Aug 12 03:05:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3TbA-0001OR-Ry; Fri, 12 Aug 2005 03:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Tb9-0001OI-AY for rtg-bfd@megatron.ietf.org; Fri, 12 Aug 2005 03:04: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 DAA07207 for ; Fri, 12 Aug 2005 03:04:57 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3U9c-0007aC-AG for rtg-bfd@ietf.org; Fri, 12 Aug 2005 03:40:36 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 08:04:48 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 08:04:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: Fri, 12 Aug 2005 08:04:48 +0100 Message-ID: Thread-Topic: Echo Function and Asymmetry - Timer negotiation Thread-Index: AcWe2D3El3gg3POjRIW55/zmU6dA5AAMvjxA To: , X-OriginalArrivalTime: 12 Aug 2005 07:04:48.0551 (UTC) FILETIME=[209CFB70:01C59F0C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org Subject: RE: Echo Function and Asymmetry - Timer negotiation 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 Reshad, > It's not clear to me what's the benefit of doing this if the=20 > asymmetric echo is being run at fast rate. Failure in any=20 > direction will be detected by the asymmetric echo and the=20 > other end (which isn't running echo) will be notified on=20 > echo failure. So it's not clear to me what's the benefit of=20 > the the guy not running echo to be receiving control=20 > packets at a faster rate. It would seem that with asymmetric=20 > echo we can still run control packets at a sedate rate in both=20 > directions. Or am I missing something? The problem is that you are assuming the system not running echo mode = will always be notified of a failure. Lets say we have a BFD session = between two systems A and B, echo mode is active on system A, but system = B is just using asynchronous mode. If there is a unidirectional failure = in the direction B->A, system A will detect the failure and will send a = BFD control packet to B indicating that there is a failure. In this = scenario, both system A and system B will be aware of the failure. However, if there is a unidirectional failure in the direction A->B, = system A will detect the failure and will send a BFD control packet to B = indicating that there is a failure. This is where the problem lies, = system B will not receive the BFD control packet because the failure is = in the direction A->B, and therefore B will not detect the failure until = it's asynchronous timer has timed out. Similarly, if there is a = bi-directional failure, system A will detect the failure and will send a = BFD control packet to B indicating that there is a failure, but again = system B will not receive the failure notification. I personally don't like echo mode as an always on fault detection = mechanism for a number of reasons: 1. Echo mode does not provide any indication of the direction/location = of the failure, it could be in the direction A->B, B->A, or it could be = a forwarding plane failure in the remote system. 2. To support symmetric failure detection times, echo mode requires = twice as many packets to be transmitted/received as asynchronous mode = does if active on both systems, and 50% more if active on just one = system. 3. The draft does not define exactly how a failure is detected in echo = mode, therefore vendors may use different methods/settings for fault = detection using echo mode. In a multi-vendor environment, this may = require translation between different methods/settings in order to = ensure symmetry in detecting failures (if they are actually user = configurable), which adds management/operational complexity. 4. Failure detection times using echo mode are more susceptible to = variations due to the packets being looped back, i.e. [downstream = propagation delay + far end switching delay + upstream propagation = delay] vs. [one way propagation delay]. I would compare BFD asynchronous mode to the use of continuity check = (CC) cells and echo mode to the use of loopback cells in ATM. In = general, loopback tests are useful as on demand tests for diagnosing = faults (e.g. for locating a fault), but are not suitable as always on = fault detection mechanisms. Regards, Richard From rtg-bfd-bounces@ietf.org Fri Aug 12 07:46:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3XzX-0001ca-LF; Fri, 12 Aug 2005 07:46:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3XzT-0001cT-F0 for rtg-bfd@megatron.ietf.org; Fri, 12 Aug 2005 07:46:25 -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 HAA17241 for ; Fri, 12 Aug 2005 07:46:21 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3YXx-0006Ty-C3 for rtg-bfd@ietf.org; Fri, 12 Aug 2005 08:22:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 12 Aug 2005 07:46:13 -0400 X-IronPort-AV: i="3.96,103,1122868800"; d="scan'208"; a="66270704:sNHT30185778" Received: from [10.83.15.53] (rtp-tnadeau-vpn4.cisco.com [10.83.15.53]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j7CBkAQm000177; Fri, 12 Aug 2005 07:46:10 -0400 (EDT) In-Reply-To: References: <20050810201652.GS5530@nexthop.com> <31E8370C-8A00-4451-AB12-73B1A696CC58@cisco.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0ACAFB10-AC15-4DD6-824C-594295D486E9@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Fri, 12 Aug 2005 07:46:03 -0400 To: Pekka Savola X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, Jeffrey Haas Subject: Re: MIB question - default BFD enable status? 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 Aug 12, 2005, at 12:54 AM, Pekka Savola wrote: > On Thu, 11 Aug 2005, Thomas D. Nadeau wrote: > >>> But even if we do, I don't think this global feature is even >>> needed -- isn't it enough to have interface, protocol, or other >>> status values which the operators can then snmpwalk through ? >>> >> >> I know of at least one implementation that has BFD as a global >> configuration. >> > > Let's take an analogue. Does the same implementation have a global > configuration to enable/disable BGP? BGP and BFD sessions seem > like similar beasts, and similar management techniques apply. I fail to see how that matters in the case of single-hop BFD. > I can only see (real) usefulness for session-based controls (and > "enable BGP/BFD" toggle without session-specific config is quite > questionable), but others might have different requirements so this > isn't really a big issue to get too excited about. When you are talking about single-hop BFD, it indeed makes sense to configure per box and/or per interface (and per session). --Tom > > -- > 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 Aug 12 09:33:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Zfa-0001Nv-1l; Fri, 12 Aug 2005 09:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZfX-0001Nn-69 for rtg-bfd@megatron.ietf.org; Fri, 12 Aug 2005 09:33:56 -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 JAA22030 for ; Fri, 12 Aug 2005 09:33:52 -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 1E3aE3-0000zl-GQ for rtg-bfd@ietf.org; Fri, 12 Aug 2005 10:09:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2005 06:33:46 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7CDXOp6006687; Fri, 12 Aug 2005 06:33:43 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 09:33:40 -0400 Received: from [192.168.1.102] ([10.86.240.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 09:33:39 -0400 Message-ID: <42FCA532.9010807@cisco.com> Date: Fri, 12 Aug 2005 09:33:38 -0400 From: Reshad Rahman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard.spencer@bt.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030001060409020808020103" X-OriginalArrivalTime: 12 Aug 2005 13:33:40.0079 (UTC) FILETIME=[73499FF0:01C59F42] X-Spam-Score: 0.5 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: rtg-bfd@ietf.org, dkatz@juniper.net Subject: Re: Echo Function and Asymmetry - Timer negotiation 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. --------------030001060409020808020103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Richard, Thanks for the response, makes sense. So in the example below where only A is using echo mode, this means that A will be sending control and echo packets at a fast rate and B will be sending control packets at the sedate rate? If that's the case all the tx burden will be on A, asymmetric echo doesn't seem fair... Regards, Reshad. richard.spencer@bt.com wrote: >Reshad, > > > >>It's not clear to me what's the benefit of doing this if the >>asymmetric echo is being run at fast rate. Failure in any >>direction will be detected by the asymmetric echo and the >>other end (which isn't running echo) will be notified on >>echo failure. So it's not clear to me what's the benefit of >>the the guy not running echo to be receiving control >>packets at a faster rate. It would seem that with asymmetric >>echo we can still run control packets at a sedate rate in both >>directions. Or am I missing something? >> >> > >The problem is that you are assuming the system not running echo mode will always be notified of a failure. Lets say we have a BFD session between two systems A and B, echo mode is active on system A, but system B is just using asynchronous mode. If there is a unidirectional failure in the direction B->A, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. In this scenario, both system A and system B will be aware of the failure. > >However, if there is a unidirectional failure in the direction A->B, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. This is where the problem lies, system B will not receive the BFD control packet because the failure is in the direction A->B, and therefore B will not detect the failure until it's asynchronous timer has timed out. Similarly, if there is a bi-directional failure, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure, but again system B will not receive the failure notification. > >I personally don't like echo mode as an always on fault detection mechanism for a number of reasons: > >1. Echo mode does not provide any indication of the direction/location of the failure, it could be in the direction A->B, B->A, or it could be a forwarding plane failure in the remote system. >2. To support symmetric failure detection times, echo mode requires twice as many packets to be transmitted/received as asynchronous mode does if active on both systems, and 50% more if active on just one system. >3. The draft does not define exactly how a failure is detected in echo mode, therefore vendors may use different methods/settings for fault detection using echo mode. In a multi-vendor environment, this may require translation between different methods/settings in order to ensure symmetry in detecting failures (if they are actually user configurable), which adds management/operational complexity. >4. Failure detection times using echo mode are more susceptible to variations due to the packets being looped back, i.e. [downstream propagation delay + far end switching delay + upstream propagation delay] vs. [one way propagation delay]. > >I would compare BFD asynchronous mode to the use of continuity check (CC) cells and echo mode to the use of loopback cells in ATM. In general, loopback tests are useful as on demand tests for diagnosing faults (e.g. for locating a fault), but are not suitable as always on fault detection mechanisms. > >Regards, >Richard > > --------------030001060409020808020103 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Richard,

Thanks for the response, makes sense. So in the example below where only A is using echo mode, this means that A will be sending control and echo packets at a fast rate and B will be sending control packets at the sedate rate? If that's the case all the tx burden will be on A, asymmetric echo doesn't seem fair...

Regards,
Reshad.

richard.spencer@bt.com wrote:
Reshad,

  
It's not clear to me what's the benefit of doing this if the 
asymmetric echo is being run at fast rate. Failure in any 
direction will be detected by the asymmetric echo and the 
other end (which isn't running echo) will be notified on 
echo failure. So it's not clear to me what's the benefit of 
the the guy not running echo to be receiving control 
packets at a faster rate. It would seem that with asymmetric 
echo we can still run control packets at a sedate rate in both 
directions. Or am I missing something?
    

The problem is that you are assuming the system not running echo mode will always be notified of a failure. Lets say we have a BFD session between two systems A and B, echo mode is active on system A, but system B is just using asynchronous mode. If there is a unidirectional failure in the direction B->A, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. In this scenario, both system A and system B will be aware of the failure.

However, if there is a unidirectional failure in the direction A->B, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. This is where the problem lies, system B will not receive the BFD control packet because the failure is in the direction A->B, and therefore B will not detect the failure until it's asynchronous timer has timed out. Similarly, if there is a bi-directional failure, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure, but again system B will not receive the failure notification.

I personally don't like echo mode as an always on fault detection mechanism for a number of reasons:

1. Echo mode does not provide any indication of the direction/location of the failure, it could be in the direction A->B, B->A, or it could be a forwarding plane failure in the remote system.
2. To support symmetric failure detection times, echo mode requires twice as many packets to be transmitted/received as asynchronous mode does if active on both systems, and 50% more if active on just one system.
3. The draft does not define exactly how a failure is detected in echo mode, therefore vendors may use different methods/settings for fault detection using echo mode. In a multi-vendor environment, this may require translation between different methods/settings in order to ensure symmetry in detecting failures (if they are actually user configurable), which adds management/operational complexity.
4. Failure detection times using echo mode are more susceptible to variations due to the packets being looped back, i.e. [downstream propagation delay + far end switching delay + upstream propagation delay] vs. [one way propagation delay].

I would compare BFD asynchronous mode to the use of continuity check (CC) cells and echo mode to the use of loopback cells in ATM. In general, loopback tests are useful as on demand tests for diagnosing faults (e.g. for locating a fault), but are not suitable as always on fault detection mechanisms.

Regards,
Richard

--------------030001060409020808020103-- From rtg-bfd-bounces@ietf.org Fri Aug 12 10:06:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3aAv-0001Bw-7m; Fri, 12 Aug 2005 10:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3aAt-0001BS-Ne for rtg-bfd@megatron.ietf.org; Fri, 12 Aug 2005 10:06:19 -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 KAA24502 for ; Fri, 12 Aug 2005 10:06:17 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ajO-0001yv-6Z for rtg-bfd@ietf.org; Fri, 12 Aug 2005 10:41:59 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 15:06:02 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 15:06:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59F46.F8BEAC20" Date: Fri, 12 Aug 2005 15:06:01 +0100 Message-ID: Thread-Topic: Echo Function and Asymmetry - Timer negotiation Thread-Index: AcWfQnf10FDqpx/URSSlmDTq5DNZvgAADqbg To: X-OriginalArrivalTime: 12 Aug 2005 14:06:02.0510 (UTC) FILETIME=[F91112E0:01C59F46] X-Spam-Score: 0.9 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: rtg-bfd@ietf.org, dkatz@juniper.net Subject: RE: Echo Function and Asymmetry - Timer negotiation 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_01C59F46.F8BEAC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Reshad, =20 In the example below, as you point out the TX burden will be on A. On = the other hand though, B will be receiving control/echo packets at a = fast rate, whilst A will be receiving control packets at a sedate rate = and echo packets at a fast rate. Therefore, from a TX and RX = perspective, things are a bit more balanced. =20 As I say though, I don't understand why anyone would want to use echo = mode, except for on demand fault diagnosis. One might argue that echo = mode tests the forwarding plane of the remote system, but just because = the remote system is looping BFD echo packets back correctly doesn't = mean that it is routing/switching all packets correctly, e.g. the = routing/switching table could be partially corrupted. =20 Regards, Richard =20 -----Original Message----- From: Reshad Rahman [mailto:rrahman@cisco.com] Sent: 12 August 2005 14:34 To: Spencer,R,Richard,XDE73 R Cc: dkatz@juniper.net; rtg-bfd@ietf.org; Tanya Shastri Subject: Re: Echo Function and Asymmetry - Timer negotiation Richard, Thanks for the response, makes sense. So in the example below where only = A is using echo mode, this means that A will be sending control and echo = packets at a fast rate and B will be sending control packets at the = sedate rate? If that's the case all the tx burden will be on A, = asymmetric echo doesn't seem fair... Regards, Reshad. richard.spencer@bt.com wrote: Reshad, =20 It's not clear to me what's the benefit of doing this if the=20 asymmetric echo is being run at fast rate. Failure in any=20 direction will be detected by the asymmetric echo and the=20 other end (which isn't running echo) will be notified on=20 echo failure. So it's not clear to me what's the benefit of=20 the the guy not running echo to be receiving control=20 packets at a faster rate. It would seem that with asymmetric=20 echo we can still run control packets at a sedate rate in both=20 directions. Or am I missing something? =20 The problem is that you are assuming the system not running echo mode = will always be notified of a failure. Lets say we have a BFD session = between two systems A and B, echo mode is active on system A, but system = B is just using asynchronous mode. If there is a unidirectional failure = in the direction B->A, system A will detect the failure and will send a = BFD control packet to B indicating that there is a failure. In this = scenario, both system A and system B will be aware of the failure. However, if there is a unidirectional failure in the direction A->B, = system A will detect the failure and will send a BFD control packet to B = indicating that there is a failure. This is where the problem lies, = system B will not receive the BFD control packet because the failure is = in the direction A->B, and therefore B will not detect the failure until = it's asynchronous timer has timed out. Similarly, if there is a = bi-directional failure, system A will detect the failure and will send a = BFD control packet to B indicating that there is a failure, but again = system B will not receive the failure notification. I personally don't like echo mode as an always on fault detection = mechanism for a number of reasons: 1. Echo mode does not provide any indication of the direction/location = of the failure, it could be in the direction A->B, B->A, or it could be = a forwarding plane failure in the remote system. 2. To support symmetric failure detection times, echo mode requires = twice as many packets to be transmitted/received as asynchronous mode = does if active on both systems, and 50% more if active on just one = system. 3. The draft does not define exactly how a failure is detected in echo = mode, therefore vendors may use different methods/settings for fault = detection using echo mode. In a multi-vendor environment, this may = require translation between different methods/settings in order to = ensure symmetry in detecting failures (if they are actually user = configurable), which adds management/operational complexity. 4. Failure detection times using echo mode are more susceptible to = variations due to the packets being looped back, i.e. [downstream = propagation delay + far end switching delay + upstream propagation = delay] vs. [one way propagation delay]. I would compare BFD asynchronous mode to the use of continuity check = (CC) cells and echo mode to the use of loopback cells in ATM. In = general, loopback tests are useful as on demand tests for diagnosing = faults (e.g. for locating a fault), but are not suitable as always on = fault detection mechanisms. Regards, Richard =20 ------_=_NextPart_001_01C59F46.F8BEAC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Reshad,
 
In=20 the example below, as you point out the TX burden will be on A. On the = other=20 hand though, B will be receiving control/echo packets at a = fast rate,=20 whilst A will be receiving control packets at a sedate rate = and echo=20 packets at a fast rate. Therefore, from a TX and RX perspective, things = are a=20 bit more balanced.
 
As I say though, I don't understand = why anyone=20 would want to use echo mode, except for on demand fault diagnosis. One = might=20 argue that echo mode tests the forwarding plane of the remote system, = but just=20 because the remote system is looping BFD echo packets back=20 correctly doesn't mean that it is routing/switching all = packets=20 correctly, e.g. the routing/switching table could be partially=20 corrupted.
 
Regards,
Richard
 
 -----Original = Message-----
From:=20 Reshad Rahman [mailto:rrahman@cisco.com]
Sent: 12 August 2005=20 14:34
To: Spencer,R,Richard,XDE73 R
Cc: = dkatz@juniper.net;=20 rtg-bfd@ietf.org; Tanya Shastri
Subject: Re: Echo Function and = Asymmetry - Timer negotiation

Richard,

Thanks=20 for the response, makes sense. So in the example below where only A is = using=20 echo mode, this means that A will be sending control and echo packets = at a=20 fast rate and B will be sending control packets at the sedate rate? If = that's=20 the case all the tx burden will be on A, asymmetric echo doesn't seem=20 fair...

Regards,
Reshad.

richard.spencer@bt.com = wrote:
Reshad,

  
It's not clear to me what's =
the benefit of doing this if the=20
asymmetric echo is being run at fast rate. Failure in any=20
direction will be detected by the asymmetric echo and the=20
other end (which isn't running echo) will be notified on=20
echo failure. So it's not clear to me what's the benefit of=20
the the guy not running echo to be receiving control=20
packets at a faster rate. It would seem that with asymmetric=20
echo we can still run control packets at a sedate rate in both=20
directions. Or am I missing something?
    

The problem is that you are assuming the system not running echo mode =
will always be notified of a failure. Lets say we have a BFD session =
between two systems A and B, echo mode is active on system A, but system =
B is just using asynchronous mode. If there is a unidirectional failure =
in the direction B->A, system A will detect the failure and will send =
a BFD control packet to B indicating that there is a failure. In this =
scenario, both system A and system B will be aware of the failure.

However, if there is a unidirectional failure in the direction A->B, =
system A will detect the failure and will send a BFD control packet to B =
indicating that there is a failure. This is where the problem lies, =
system B will not receive the BFD control packet because the failure is =
in the direction A->B, and therefore B will not detect the failure =
until it's asynchronous timer has timed out. Similarly, if there is a =
bi-directional failure, system A will detect the failure and will send a =
BFD control packet to B indicating that there is a failure, but again =
system B will not receive the failure notification.

I personally don't like echo mode as an always on fault detection =
mechanism for a number of reasons:

1. Echo mode does not provide any indication of the direction/location =
of the failure, it could be in the direction A->B, B->A, or it =
could be a forwarding plane failure in the remote system.
2. To support symmetric failure detection times, echo mode requires =
twice as many packets to be transmitted/received as asynchronous mode =
does if active on both systems, and 50% more if active on just one =
system.
3. The draft does not define exactly how a failure is detected in echo =
mode, therefore vendors may use different methods/settings for fault =
detection using echo mode. In a multi-vendor environment, this may =
require translation between different methods/settings in order to =
ensure symmetry in detecting failures (if they are actually user =
configurable), which adds management/operational complexity.
4. Failure detection times using echo mode are more susceptible to =
variations due to the packets being looped back, i.e. [downstream =
propagation delay + far end switching delay + upstream propagation =
delay] vs. [one way propagation delay].

I would compare BFD asynchronous mode to the use of continuity check =
(CC) cells and echo mode to the use of loopback cells in ATM. In =
general, loopback tests are useful as on demand tests for diagnosing =
faults (e.g. for locating a fault), but are not suitable as always on =
fault detection mechanisms.

Regards,
Richard

------_=_NextPart_001_01C59F46.F8BEAC20-- From rtg-bfd-bounces@ietf.org Fri Aug 12 11:22:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bMy-0006ml-5h; Fri, 12 Aug 2005 11:22:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bMw-0006mZ-1o for rtg-bfd@megatron.ietf.org; Fri, 12 Aug 2005 11:22:50 -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 LAA00830 for ; Fri, 12 Aug 2005 11:22:47 -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 1E3bvT-0004cs-8E for rtg-bfd@ietf.org; Fri, 12 Aug 2005 11:58:32 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2005 08:22:36 -0700 X-IronPort-AV: i="3.96,103,1122879600"; d="scan'208"; a="331693552:sNHT725347162" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7CFMQQM000756; Fri, 12 Aug 2005 08:22:27 -0700 (PDT) Received: from [10.83.142.178] (cfcentral.cisco.com [64.101.210.32]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA19068; Fri, 12 Aug 2005 10:22:29 -0500 (CDT) Mime-Version: 1.0 X-Sender: wardd@127.0.0.1 Message-Id: Date: Fri, 12 Aug 2005 10:22:34 -0500 To: rtg-bfd@ietf.org From: David Ward Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: jhaas@nexthop.com, dward@cisco.com, dkatz@juniper.net Subject: Notes IETF 63 BFD Working Group 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 IETF 63 BFD WG Meeting Minutes Thanks to Tom Nadeau for taking the minutes. Wednesday, August 3 9:00 AM Dave: Introduction. Read Note Well. Short agenda: Dave will talk about changes, applicability. Presentation by Suping. 0) Status of the drafts. LC base specs. Technically, last call is finished. Released an intermediate draft containing only editorial comments. No comments (0) during LC. Assuming that most folks are happy with single-hop and MH specs. Will send out call for implementation experience. MH spec. minor tweak. MIB: may need another spin. Will go to LC after quick review to determine if any changes needed. Tom, is this okay? Yes. MPLS spec. WG LC start next week. Generic spec. version 00 is out. version -01 is imminent. Potentially to LC after draft settles down or 3 week comment period. Milestones: Status to be updated. Expect last meeting in Vancouver. Discuss specification changes details: Base spec., SH, MH spec. Major change is a port change used to discern MH or SH cases. Comments on new version of MIB? Dave asks for comments. No comments. New author set on MPLS draft. Basic changes to draft are to send original port, but replies will use the MH port on replies. Dave asks room for comments. No comments. 1) Describes diffs between generic draft 00 and 01. Dave: Alex Z. is here. Can we get a MIB Doc review for MIB? Tom: can we do the LC and MIB doctor review at the same time? Alex: I will send an email to MIB doctor pool and get one assigned. 0a) Dave: back to diffs... Dave: I would like comments on multiple topologies or adj multiplexed over one interface. Must have proper packet demux before session demux. Is this a good change? PekkaS: Yes, this is a good change. BFD should not be used to carry any other application-specific information. Lowest level of control plane should be attached to the BFD session. Others should be keyed to the events (control dependencies) from this FSM. Last slide is on static routes. Must be configured on both end points to work. Recommending BFD is bootstrapped the same way its done for the static case. Transition to/from states processing should be the same as non-static case. BFD should be run inside tunnels for max to operate at most basic level. Dave: should this draft be informational? Alex: could be okay for standards track. Rob (Laurel): you said in a hierarchy that BFD should interact with the lowest level. The lowest level should bootstrap too. So from a bootstrapping AND a listening situation BFD should interact with the lowest level? Clarify? Dave: You can bootstrap the BFD session using the best method. The lowest point of the control plane should interact with the BFD session. Rob: for iBGP, ignore BFD. don't set up BFD sessions to loopbacks. Let OSPF/ISIS do it. Its not aware that BFD is running. Dave: There is nothing subtle there. You can do whatever you think makes sense. But the recommendation is not to run BFD to loopbacks or IBGP sessions. Use lower layer. PekkaS: We dont have any documents yet that describe the static route case nor do these show how to run this in iBGP. Dave: I think we do. We have statics in non-control plane portion of the documents. You generally don't want to run this for iBGP peers; you run it on IGP. In MH or eBGP case we do explain why this is needed. External BGP reacts to the downstate of the directly connected link or fwding plane. We describe the l3 state and tear down the session quickly. Maybe we need stronger text? With static routes we don't do bootstrapping, so when its configured you can have a BFD configuration too. Local decision. PekkaS: What I was looking for is guidance of what to do in these cases, to have consistent implementations. Dave: Whether or not you deactivate the route is a local decision, but will most often result in not transmitting data. PekkaS: I still don't get it. Dave: The sentence should state that you can stop xmitting data and should withdraw the route if redistributed. PekkaS: Another eBGP question. Issues with graceful restart? Dave: It could: When receiving a BFD failure notification, in eBGP you would tear down the state and if the router was enabled for Graceful Restart, it should not perform GR. We are only detecting failure of data plane. Tom: in MPLS draft I think that we recommended that you do the graceful restart procedures if sessions are lost. Dave: We can suggest some language in draft. In the eBGP case the assumptions of graceful restart might want to be avoided. The assumption of GR is that the fwding plane is still working. BFD detects that it is not. Therefore, you do not want to announce GR if the assumptions of GR are not met. Alia: I like the discussion of the lowest level of the control plane attachment to BFD. What I want is the text to state that the BFD session down notification should take the same action for the other applications. Dave: We state that in the SH draft, but in the BFD Generic draft we try not to use "BFD failure?" == "L2 down" Its whether or not the text would be confusing. It probably would be as BFD doesn't limit itself to L2 only. Alia: It seems that if you don't have the text that way you could have some odd corner cases. Something to give the philosophy/guidance. PekkaS: Just to clarify that my initial proposal for this text was to explicitly take explicit action when the event comes in. I have no objections if some objections would like to remove it from the routing when the if goes down; might be an implementation case. Dave: I think we are going to put down the routing case. I see your point. We can state that if the static route goes down, one SHOULD withdraw the route. Q: Where are the drafts? Dave: -01 is coming out ASAP. Dave: Is there any dissent to make the gen draft a WG doc? room: none. 1)Supping preso: Dave: anyone to present idea? I will present slides on BFD init with BGP/static routes... Dave: Has anyone read the draft. PekkaS: Before we have this clarifying discussion. I am a bit sympathetic to the first bullet. From the perspective of the operator. This was before the generic draft came out. Tom: Do not make a WG document; clarify the existing drafts. Richard Spencer: Should we put all applications in this draft? Are we going to end up with multiple drafts? If there is something to be standardized to implement interop. we need to agree what. In the static case, we need to configure the src/dst points manually. I think if you want to this draft become a WG draft,then we need to say what is missing from current drafts. If there is anything missing, then we should incorporate it into existing drafts. Dave: I concur. I do not think we need to extend BGP, and to clarify what to do in the base documents. So the BGP extensions are unnecessary to bring up a BFD session, and so the extentions as prescribed are not applicable to get the BFD session up. No issue to be solved here. WRT finishing generic applicability -- I strongly prefer that we do not have a draft for every application. Instead have a generic application document that includes these. Dave to the Room: are there any WG members that want to accept this as a WG draft? None. Tom: Ask coauthors to clarify text in generic draft if anything is missing? Dave: Have already done so. PekkaS: Maybe some appendices to explicitly clarify popular cases. Dave: I know we have used the "appendix out" in the past, but I think we will just put it inline into the document. As we are going to add the four sentences that were requested. Dave: Comments/questions? None. Attempt is to have a short LC after documents have been updated. Adjourn From rtg-bfd-bounces@ietf.org Fri Aug 12 16:03:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3fkk-0005j1-2S; Fri, 12 Aug 2005 16:03:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3fkh-0005g3-R6 for rtg-bfd@megatron.ietf.org; Fri, 12 Aug 2005 16:03: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 QAA17893 for ; Fri, 12 Aug 2005 16:03:36 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3gJD-0004oO-Es for rtg-bfd@ietf.org; Fri, 12 Aug 2005 16:39:20 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 12 Aug 2005 16:03:24 -0400 X-IronPort-AV: i="3.96,103,1122868800"; d="scan'208,217"; a="66332050:sNHT47018654" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7CK30R7016589; Fri, 12 Aug 2005 16:03:22 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 16:03:14 -0400 Received: from [192.168.1.102] ([10.86.240.185]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 16:03:13 -0400 Message-ID: <42FD007E.6000408@cisco.com> Date: Fri, 12 Aug 2005 16:03:10 -0400 From: Reshad Rahman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard.spencer@bt.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040509080905090804060903" X-OriginalArrivalTime: 12 Aug 2005 20:03:13.0356 (UTC) FILETIME=[DED8A8C0:01C59F78] X-Spam-Score: 1.1 (+) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: rtg-bfd@ietf.org, dkatz@juniper.net Subject: Re: Echo Function and Asymmetry - Timer negotiation 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. --------------040509080905090804060903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Richard, Please see inline. richard.spencer@bt.com wrote: > Hi Reshad, > > In the example below, as you point out the TX burden will be on A. On > the other hand though, B will be receiving control/echo packets at a > fast rate, whilst A will be receiving control packets at a sedate rate > and echo packets at a fast rate. Therefore, from a TX and RX > perspective, things are a bit more balanced. B is receiving echo packets but it is forwarding/looping-back the echo packets. I should have been clearer: I wasn't referring to raw tx/rx but to the host-stack tx/rx. And the burden on the host-stack is bigger on A. > > As I say though, I don't understand why anyone would want to use echo > mode, except for on demand fault diagnosis. One might argue that echo > mode tests the forwarding plane of the remote system, but just because > the remote system is looping BFD echo packets back correctly doesn't > mean that it is routing/switching all packets correctly, e.g. the > routing/switching table could be partially corrupted. > I agree that echo doesn't detect partial failures. But echo mode does detect failures which occur as a result of the whole fwding engine being hosed. I think echo has the benefit of decreasing the chances of false-positives due to spikes in CPU usage. Regards, Reshad. > Regards, > Richard > > -----Original Message----- > From: Reshad Rahman [mailto:rrahman@cisco.com] > Sent: 12 August 2005 14:34 > To: Spencer,R,Richard,XDE73 R > Cc: dkatz@juniper.net; rtg-bfd@ietf.org; Tanya Shastri > Subject: Re: Echo Function and Asymmetry - Timer negotiation > > Richard, > > Thanks for the response, makes sense. So in the example below > where only A is using echo mode, this means that A will be sending > control and echo packets at a fast rate and B will be sending > control packets at the sedate rate? If that's the case all the tx > burden will be on A, asymmetric echo doesn't seem fair... > > Regards, > Reshad. > > richard.spencer@bt.com wrote: > >>Reshad, >> >> >> >>>It's not clear to me what's the benefit of doing this if the >>>asymmetric echo is being run at fast rate. Failure in any >>>direction will be detected by the asymmetric echo and the >>>other end (which isn't running echo) will be notified on >>>echo failure. So it's not clear to me what's the benefit of >>>the the guy not running echo to be receiving control >>>packets at a faster rate. It would seem that with asymmetric >>>echo we can still run control packets at a sedate rate in both >>>directions. Or am I missing something? >>> >>> >> >>The problem is that you are assuming the system not running echo mode will always be notified of a failure. Lets say we have a BFD session between two systems A and B, echo mode is active on system A, but system B is just using asynchronous mode. If there is a unidirectional failure in the direction B->A, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. In this scenario, both system A and system B will be aware of the failure. >> >>However, if there is a unidirectional failure in the direction A->B, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. This is where the problem lies, system B will not receive the BFD control packet because the failure is in the direction A->B, and therefore B will not detect the failure until it's asynchronous timer has timed out. Similarly, if there is a bi-directional failure, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure, but again system B will not receive the failure notification. >> >>I personally don't like echo mode as an always on fault detection mechanism for a number of reasons: >> >>1. Echo mode does not provide any indication of the direction/location of the failure, it could be in the direction A->B, B->A, or it could be a forwarding plane failure in the remote system. >>2. To support symmetric failure detection times, echo mode requires twice as many packets to be transmitted/received as asynchronous mode does if active on both systems, and 50% more if active on just one system. >>3. The draft does not define exactly how a failure is detected in echo mode, therefore vendors may use different methods/settings for fault detection using echo mode. In a multi-vendor environment, this may require translation between different methods/settings in order to ensure symmetry in detecting failures (if they are actually user configurable), which adds management/operational complexity. >>4. Failure detection times using echo mode are more susceptible to variations due to the packets being looped back, i.e. [downstream propagation delay + far end switching delay + upstream propagation delay] vs. [one way propagation delay]. >> >>I would compare BFD asynchronous mode to the use of continuity check (CC) cells and echo mode to the use of loopback cells in ATM. In general, loopback tests are useful as on demand tests for diagnosing faults (e.g. for locating a fault), but are not suitable as always on fault detection mechanisms. >> >>Regards, >>Richard >> >> > --------------040509080905090804060903 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Richard,

Please see inline.

richard.spencer@bt.com wrote:
Hi Reshad,
 
In the example below, as you point out the TX burden will be on A. On the other hand though, B will be receiving control/echo packets at a fast rate, whilst A will be receiving control packets at a sedate rate and echo packets at a fast rate. Therefore, from a TX and RX perspective, things are a bit more balanced.
B is receiving echo packets but it is forwarding/looping-back the echo packets. I should have been clearer: I wasn't referring to raw tx/rx but to the host-stack tx/rx. And the burden on the host-stack is bigger on A.
 
As I say though, I don't understand why anyone would want to use echo mode, except for on demand fault diagnosis. One might argue that echo mode tests the forwarding plane of the remote system, but just because the remote system is looping BFD echo packets back correctly doesn't mean that it is routing/switching all packets correctly, e.g. the routing/switching table could be partially corrupted.

I agree that echo doesn't detect partial failures. But echo mode does detect failures which occur as a result of the whole fwding engine being hosed.

I think echo has the benefit of decreasing the chances of false-positives due to spikes in CPU usage.

Regards,
Reshad.
Regards,
Richard
 
 -----Original Message-----
From: Reshad Rahman [mailto:rrahman@cisco.com]
Sent: 12 August 2005 14:34
To: Spencer,R,Richard,XDE73 R
Cc: dkatz@juniper.net; rtg-bfd@ietf.org; Tanya Shastri
Subject: Re: Echo Function and Asymmetry - Timer negotiation

Richard,

Thanks for the response, makes sense. So in the example below where only A is using echo mode, this means that A will be sending control and echo packets at a fast rate and B will be sending control packets at the sedate rate? If that's the case all the tx burden will be on A, asymmetric echo doesn't seem fair...

Regards,
Reshad.

richard.spencer@bt.com wrote:
Reshad,

  
It's not clear to me what's the benefit of doing this if the 
asymmetric echo is being run at fast rate. Failure in any 
direction will be detected by the asymmetric echo and the 
other end (which isn't running echo) will be notified on 
echo failure. So it's not clear to me what's the benefit of 
the the guy not running echo to be receiving control 
packets at a faster rate. It would seem that with asymmetric 
echo we can still run control packets at a sedate rate in both 
directions. Or am I missing something?
    

The problem is that you are assuming the system not running echo mode will always be notified of a failure. Lets say we have a BFD session between two systems A and B, echo mode is active on system A, but system B is just using asynchronous mode. If there is a unidirectional failure in the direction B->A, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. In this scenario, both system A and system B will be aware of the failure.

However, if there is a unidirectional failure in the direction A->B, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. This is where the problem lies, system B will not receive the BFD control packet because the failure is in the direction A->B, and therefore B will not detect the failure until it's asynchronous timer has timed out. Similarly, if there is a bi-directional failure, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure, but again system B will not receive the failure notification.

I personally don't like echo mode as an always on fault detection mechanism for a number of reasons:

1. Echo mode does not provide any indication of the direction/location of the failure, it could be in the direction A->B, B->A, or it could be a forwarding plane failure in the remote system.
2. To support symmetric failure detection times, echo mode requires twice as many packets to be transmitted/received as asynchronous mode does if active on both systems, and 50% more if active on just one system.
3. The draft does not define exactly how a failure is detected in echo mode, therefore vendors may use different methods/settings for fault detection using echo mode. In a multi-vendor environment, this may require translation between different methods/settings in order to ensure symmetry in detecting failures (if they are actually user configurable), which adds management/operational complexity.
4. Failure detection times using echo mode are more susceptible to variations due to the packets being looped back, i.e. [downstream propagation delay + far end switching delay + upstream propagation delay] vs. [one way propagation delay].

I would compare BFD asynchronous mode to the use of continuity check (CC) cells and echo mode to the use of loopback cells in ATM. In general, loopback tests are useful as on demand tests for diagnosing faults (e.g. for locating a fault), but are not suitable as always on fault detection mechanisms.

Regards,
Richard


--------------040509080905090804060903-- From rtg-bfd-bounces@ietf.org Mon Aug 15 06:44:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4cSB-0003uT-MQ; Mon, 15 Aug 2005 06:44:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4cS9-0003uJ-V0 for rtg-bfd@megatron.ietf.org; Mon, 15 Aug 2005 06:44: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 GAA25317 for ; Mon, 15 Aug 2005 06:44:23 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4d1F-0003Sc-A7 for rtg-bfd@ietf.org; Mon, 15 Aug 2005 07:20:43 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 11:43:57 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Aug 2005 11:44:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: Mon, 15 Aug 2005 11:44:03 +0100 Message-ID: Thread-Topic: MIB question - default BFD enable status? Thread-Index: AcWe+k612SMzZ2XNQR2pFHZoijdeewCh1+Kg To: , X-OriginalArrivalTime: 15 Aug 2005 10:44:04.0300 (UTC) FILETIME=[414A38C0:01C5A186] X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org, jhaas@nexthop.com Subject: RE: MIB question - default BFD enable status? 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 Pekka, BFD needs to be "configured" at the forwarding protocol level (i.e. = IPv4, IPv6, MPLS), and in some cases at the control protocol level (e.g. = per static route, per EBGP peer). However, ideally an implementation = will also support the ability to "enable/disable" configured BFD = sessions at the global level, as well as at the per session/interface = level. The global enable/disable command is useful for router = commissioning scenarios (e.g. to wait until the other nodes in the = network have been configured before enabling BFD) and for = troubleshooting scenarios (e.g. if BFD is not operating correctly on a = particular system). To use your BGP analogy, BGP sessions are configured on a per peer = basis, but all BGP implementation should support the ability to = clear/reset sessions at the global level, as well as at the peer level. Regarding the original question, I agree with Jeff/Tom that the default = value for the MIB should be 'disabled', and that r-o should suffice. Regards, Richard > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On > Behalf Of Pekka Savola > Sent: 12 August 2005 05:55 > To: Thomas D. Nadeau > Cc: rtg-bfd@ietf.org; Jeffrey Haas > Subject: Re: MIB question - default BFD enable status? >=20 >=20 > On Thu, 11 Aug 2005, Thomas D. Nadeau wrote: > >> But even if we do, I don't think this global feature is=20 > even needed --=20 > >> isn't it enough to have interface, protocol, or other=20 > status values which=20 > >> the operators can then snmpwalk through ? > > > > I know of at least one implementation that has BFD as a global > > configuration. >=20 > Let's take an analogue. Does the same implementation have a global=20 > configuration to enable/disable BGP? BGP and BFD sessions seem like=20 > similar beasts, and similar management techniques apply. >=20 > I can only see (real) usefulness for session-based controls (and=20 > "enable BGP/BFD" toggle without session-specific config is quite=20 > questionable), but others might have different requirements so this=20 > isn't really a big issue to get too excited about. >=20 > --=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 Mon Aug 15 12:00:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hOU-0002NW-W1; Mon, 15 Aug 2005 12:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hOT-0002NQ-Ti for rtg-bfd@megatron.ietf.org; Mon, 15 Aug 2005 12:00:58 -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 MAA10252 for ; Mon, 15 Aug 2005 12:00:55 -0400 (EDT) Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4hxc-00026F-Q3 for rtg-bfd@ietf.org; Mon, 15 Aug 2005 12:37:18 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 71DAE163C93; Mon, 15 Aug 2005 16:00:41 +0000 (GMT) Received: from gateout02.mbox.net [165.212.64.22] by gateout02.mbox.net via mtad (C8.MAIN.3.17K) with ESMTP id 882JHoqaO0004Mo2; Mon, 15 Aug 2005 16:00:40 GMT Received: from gw4.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Mon, 15 Aug 2005 16:00:40 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw4.EXCHPROD.USA.NET X-USANET-MsgId: XID911JHoqaO3211Xo2 Received: from localhost ([65.247.36.31]) by gw4.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 10:00:39 -0600 Date: Mon, 15 Aug 2005 12:00:39 -0400 From: Jeffrey Haas To: Pekka Savola Message-ID: <20050815160038.GA5530@nexthop.com> References: <20050810201652.GS5530@nexthop.com> <31E8370C-8A00-4451-AB12-73B1A696CC58@cisco.com> 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: 15 Aug 2005 16:00:39.0952 (UTC) FILETIME=[7B94B100:01C5A1B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Thomas D. Nadeau" , rtg-bfd@ietf.org Subject: Re: MIB question - default BFD enable status? 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, Aug 12, 2005 at 07:54:59AM +0300, Pekka Savola wrote: > I can only see (real) usefulness for session-based controls (and > "enable BGP/BFD" toggle without session-specific config is quite > questionable), but others might have different requirements so this > isn't really a big issue to get too excited about. I believe that the ability to configure BFD sessions from within the MIB to probably be a dead-end. In order for BFD to function well it requires strong coordination with other protocols. In other words, it doesn't make a good stand-alone protocol. Thus, as part of my MIB review comments to Tom, I'm suggesting that many of the read-create aspects of the session table be removed or, at best, be made read-write. Arguments the other way would be appreciated during this review period. -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Mon Aug 15 16:14:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lLu-0004Mo-Ra; Mon, 15 Aug 2005 16:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lLs-0004Hq-F0 for rtg-bfd@megatron.ietf.org; Mon, 15 Aug 2005 16:14: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 QAA00837 for ; Mon, 15 Aug 2005 16:14:30 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4lv3-0002aB-3h for rtg-bfd@ietf.org; Mon, 15 Aug 2005 16:50:54 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 21:14:20 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Aug 2005 21:14:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: Mon, 15 Aug 2005 21:14:19 +0100 Message-ID: Thread-Topic: Echo Function and Asymmetry - Timer negotiation Thread-Index: AcWfeOZhtdAYLS1cTD2FzJJp6q5QgACLVrTw To: X-OriginalArrivalTime: 15 Aug 2005 20:14:20.0970 (UTC) FILETIME=[EC03B8A0:01C5A1D5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org, dkatz@juniper.net Subject: RE: Echo Function and Asymmetry - Timer negotiation 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 Reshad, Regarding your comment about echo mode decreasing the chances of = false-positives due to spikes in CPU usage, I believe this benefit is = implementation dependant. The argument I have heard put forward is that = if a remote BFD peer's CPU becomes overloaded when using asynchronous = mode, BFD control packets may not be sent/processed in a timely manner = causing the BFD session to be declared down even though there hasn't = been a loss in connectivity. Using echo mode is perceived to solve this = issue due to the fact that echo packets are switched using the = forwarding plane h/w rather than the CPU. Firstly, some BFD systems (e.g. simple low cost access devices with = minimal IP functionality) may process/forward all IP packets using the = CPU, in which case, if there are CPU spikes BFD echo packets will be = affected in the same way that BFD control packets are (assuming they are = given the same priority). Secondly, even if an implementation switches received echo packets in = h/w, it may still use its CPU to generate/process its own echo packets. = In which case, if a system's CPU resources become overloaded, although = it will continue to switch back echo packets that it receives from its = peer, it may fail to process its own echo packets in time and the = session will be declared down anyway. Of course, this is also depends on = what constitutes a failure using echo mode as this is implementation = dependant (it isn't defined in any of the drafts). Therefore, to ensure an echo mode BFD implementation is not affected by = CPU usage spikes, it must not generate, process, or switch BFD packets = using the CPU, i.e. all BFD echo packet generation/processing must be = done in hardware.=20 In order to determine how significant the chance of decreasing the = chance of false-positives using echo mode is, it would be interesting to = hear from vendors if full h/w based BFD echo packet processing is the = exception or the norm? Regards, Richard -----Original Message----- From: Reshad Rahman [mailto:rrahman@cisco.com] Sent: 12 August 2005 21:03 To: Spencer,R,Richard,XDE73 R Cc: dkatz@juniper.net; rtg-bfd@ietf.org; tanyas@cisco.com Subject: Re: Echo Function and Asymmetry - Timer negotiation Hi Richard, Please see inline. richard.spencer@bt.com wrote:=20 Hi Reshad, In the example below, as you point out the TX burden will be on A. On = the other hand though, B will be receiving control/echo packets at a = fast rate, whilst A will be receiving control packets at a sedate rate = and echo packets at a fast rate. Therefore, from a TX and RX = perspective, things are a bit more balanced. B is receiving echo packets but it is forwarding/looping-back the echo = packets. I should have been clearer: I wasn't referring to raw tx/rx but = to the host-stack tx/rx. And the burden on the host-stack is bigger on = A. As I say though, I don't understand why anyone would want to use echo = mode, except for on demand fault diagnosis. One might argue that echo = mode tests the forwarding plane of the remote system, but just because = the remote system is looping BFD echo packets back correctly doesn't = mean that it is routing/switching all packets correctly, e.g. the = routing/switching table could be partially corrupted. I agree that echo doesn't detect partial failures. But echo mode does = detect failures which occur as a result of the whole fwding engine being = hosed. I think echo has the benefit of decreasing the chances of = false-positives due to spikes in CPU usage. Regards, Reshad. Regards, Richard -----Original Message----- From: Reshad Rahman [mailto:rrahman@cisco.com] Sent: 12 August 2005 14:34 To: Spencer,R,Richard,XDE73 R Cc: dkatz@juniper.net; rtg-bfd@ietf.org; Tanya Shastri Subject: Re: Echo Function and Asymmetry - Timer negotiation Richard, Thanks for the response, makes sense. So in the example below where only = A is using echo mode, this means that A will be sending control and echo = packets at a fast rate and B will be sending control packets at the = sedate rate? If that's the case all the tx burden will be on A, = asymmetric echo doesn't seem fair... Regards, Reshad. richard.spencer@bt.com wrote: Reshad, =20 It's not clear to me what's the benefit of doing this if the=20 asymmetric echo is being run at fast rate. Failure in any=20 direction will be detected by the asymmetric echo and the=20 other end (which isn't running echo) will be notified on=20 echo failure. So it's not clear to me what's the benefit of=20 the the guy not running echo to be receiving control=20 packets at a faster rate. It would seem that with asymmetric=20 echo we can still run control packets at a sedate rate in both=20 directions. Or am I missing something? =20 The problem is that you are assuming the system not running echo mode = will always be notified of a failure. Lets say we have a BFD session = between two systems A and B, echo mode is active on system A, but system = B is just using asynchronous mode. If there is a unidirectional failure = in the direction B->A, system A will detect the failure and will send a = BFD control packet to B indicating that there is a failure. In this = scenario, both system A and system B will be aware of the failure. However, if there is a unidirectional failure in the direction A->B, = system A will detect the failure and will send a BFD control packet to B = indicating that there is a failure. This is where the problem lies, = system B will not receive the BFD control packet because the failure is = in the direction A->B, and therefore B will not detect the failure until = it's asynchronous timer has timed out. Similarly, if there is a = bi-directional failure, system A will detect the failure and will send a = BFD control packet to B indicating that there is a failure, but again = system B will not receive the failure notification. I personally don't like echo mode as an always on fault detection = mechanism for a number of reasons: 1. Echo mode does not provide any indication of the direction/location = of the failure, it could be in the direction A->B, B->A, or it could be = a forwarding plane failure in the remote system. 2. To support symmetric failure detection times, echo mode requires = twice as many packets to be transmitted/received as asynchronous mode = does if active on both systems, and 50% more if active on just one = system. 3. The draft does not define exactly how a failure is detected in echo = mode, therefore vendors may use different methods/settings for fault = detection using echo mode. In a multi-vendor environment, this may = require translation between different methods/settings in order to = ensure symmetry in detecting failures (if they are actually user = configurable), which adds management/operational complexity. 4. Failure detection times using echo mode are more susceptible to = variations due to the packets being looped back, i.e. [downstream = propagation delay + far end switching delay + upstream propagation = delay] vs. [one way propagation delay]. I would compare BFD asynchronous mode to the use of continuity check = (CC) cells and echo mode to the use of loopback cells in ATM. In = general, loopback tests are useful as on demand tests for diagnosing = faults (e.g. for locating a fault), but are not suitable as always on = fault detection mechanisms. Regards, Richard =20 From rtg-bfd-bounces@ietf.org Mon Aug 15 17:21:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mOO-0003mX-L9; Mon, 15 Aug 2005 17:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mON-0003l6-5T for rtg-bfd@megatron.ietf.org; Mon, 15 Aug 2005 17:21:11 -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 RAA05272 for ; Mon, 15 Aug 2005 17:21:09 -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 1E4mxX-0004al-MR for rtg-bfd@ietf.org; Mon, 15 Aug 2005 17:57:34 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2005 14:20:59 -0700 X-IronPort-AV: i="3.96,108,1122879600"; d="scan'208"; a="332408380:sNHT34387544" 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 j7FLKl0N029990; Mon, 15 Aug 2005 14:20:55 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 17:20:39 -0400 Received: from [192.168.1.102] ([10.86.240.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 17:20:38 -0400 Message-ID: <43010724.3050303@cisco.com> Date: Mon, 15 Aug 2005 17:20:36 -0400 From: Reshad Rahman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard.spencer@bt.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2005 21:20:38.0833 (UTC) FILETIME=[2F017210:01C5A1DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, dkatz@juniper.net Subject: Re: Echo Function and Asymmetry - Timer negotiation 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 Richard, richard.spencer@bt.com wrote: >Hi Reshad, > >Regarding your comment about echo mode decreasing the chances of false-positives due to spikes in CPU usage, I believe this benefit is implementation dependant. > I agree that this is implementation specific. But I do believe one of the goals behind the echo mode was to decrease the chances of false-postives. This is just my understanding, there's no mention of this in the specs, so I could be wrong. >The argument I have heard put forward is that if a remote BFD peer's CPU becomes overloaded when using asynchronous mode, BFD control packets may not be sent/processed in a timely manner causing the BFD session to be declared down even though there hasn't been a loss in connectivity. Using echo mode is perceived to solve this issue due to the fact that echo packets are switched using the forwarding plane h/w rather than the CPU. > >Firstly, some BFD systems (e.g. simple low cost access devices with minimal IP functionality) may process/forward all IP packets using the CPU, in which case, if there are CPU spikes BFD echo packets will be affected in the same way that BFD control packets are (assuming they are given the same priority). > > Yes this can happen on some systems, although typically packet forwarding does get higher priority. >Secondly, even if an implementation switches received echo packets in h/w, it may still use its CPU to generate/process its own echo packets. In which case, if a system's CPU resources become overloaded, although it will continue to switch back echo packets that it receives from its peer, it may fail to process its own echo packets in time and the session will be declared down anyway. > If the system's CPU is overloaded, then most likely the system isn't sending echo packets either. But again, this is implementation dependent. >Of course, this is also depends on what constitutes a failure using echo mode as this is implementation dependant (it isn't defined in any of the drafts). > > I agree. >Therefore, to ensure an echo mode BFD implementation is not affected by CPU usage spikes, it must not generate, process, or switch BFD packets using the CPU, i.e. all BFD echo packet generation/processing must be done in hardware. > > Even if the echo packets are generated and processed by s/w, I think it's possible to have an implementation which woudn't detect echo failure (of course as you pointed out this depends on the definition of echo failure) if the CPU gets busy (assuming echo packets are being switched back by the remote end). Regards, Reshad. >In order to determine how significant the chance of decreasing the chance of false-positives using echo mode is, it would be interesting to hear from vendors if full h/w based BFD echo packet processing is the exception or the norm? > >Regards, >Richard > >-----Original Message----- >From: Reshad Rahman [mailto:rrahman@cisco.com] >Sent: 12 August 2005 21:03 >To: Spencer,R,Richard,XDE73 R >Cc: dkatz@juniper.net; rtg-bfd@ietf.org; tanyas@cisco.com >Subject: Re: Echo Function and Asymmetry - Timer negotiation > > >Hi Richard, > >Please see inline. > >richard.spencer@bt.com wrote: >Hi Reshad, > >In the example below, as you point out the TX burden will be on A. On the other hand though, B will be receiving control/echo packets at a fast rate, whilst A will be receiving control packets at a sedate rate and echo packets at a fast rate. Therefore, from a TX and RX perspective, things are a bit more balanced. >B is receiving echo packets but it is forwarding/looping-back the echo packets. I should have been clearer: I wasn't referring to raw tx/rx but to the host-stack tx/rx. And the burden on the host-stack is bigger on A. > > >As I say though, I don't understand why anyone would want to use echo mode, except for on demand fault diagnosis. One might argue that echo mode tests the forwarding plane of the remote system, but just because the remote system is looping BFD echo packets back correctly doesn't mean that it is routing/switching all packets correctly, e.g. the routing/switching table could be partially corrupted. > > >I agree that echo doesn't detect partial failures. But echo mode does detect failures which occur as a result of the whole fwding engine being hosed. > >I think echo has the benefit of decreasing the chances of false-positives due to spikes in CPU usage. > >Regards, >Reshad. > >Regards, >Richard > > -----Original Message----- >From: Reshad Rahman [mailto:rrahman@cisco.com] >Sent: 12 August 2005 14:34 >To: Spencer,R,Richard,XDE73 R >Cc: dkatz@juniper.net; rtg-bfd@ietf.org; Tanya Shastri >Subject: Re: Echo Function and Asymmetry - Timer negotiation > > >Richard, > >Thanks for the response, makes sense. So in the example below where only A is using echo mode, this means that A will be sending control and echo packets at a fast rate and B will be sending control packets at the sedate rate? If that's the case all the tx burden will be on A, asymmetric echo doesn't seem fair... > >Regards, >Reshad. > >richard.spencer@bt.com wrote: > >Reshad, > > >It's not clear to me what's the benefit of doing this if the >asymmetric echo is being run at fast rate. Failure in any >direction will be detected by the asymmetric echo and the >other end (which isn't running echo) will be notified on >echo failure. So it's not clear to me what's the benefit of >the the guy not running echo to be receiving control >packets at a faster rate. It would seem that with asymmetric >echo we can still run control packets at a sedate rate in both >directions. Or am I missing something? > > >The problem is that you are assuming the system not running echo mode will always be notified of a failure. Lets say we have a BFD session between two systems A and B, echo mode is active on system A, but system B is just using asynchronous mode. If there is a unidirectional failure in the direction B->A, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. In this scenario, both system A and system B will be aware of the failure. > >However, if there is a unidirectional failure in the direction A->B, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. This is where the problem lies, system B will not receive the BFD control packet because the failure is in the direction A->B, and therefore B will not detect the failure until it's asynchronous timer has timed out. Similarly, if there is a bi-directional failure, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure, but again system B will not receive the failure notification. > >I personally don't like echo mode as an always on fault detection mechanism for a number of reasons: > >1. Echo mode does not provide any indication of the direction/location of the failure, it could be in the direction A->B, B->A, or it could be a forwarding plane failure in the remote system. >2. To support symmetric failure detection times, echo mode requires twice as many packets to be transmitted/received as asynchronous mode does if active on both systems, and 50% more if active on just one system. >3. The draft does not define exactly how a failure is detected in echo mode, therefore vendors may use different methods/settings for fault detection using echo mode. In a multi-vendor environment, this may require translation between different methods/settings in order to ensure symmetry in detecting failures (if they are actually user configurable), which adds management/operational complexity. >4. Failure detection times using echo mode are more susceptible to variations due to the packets being looped back, i.e. [downstream propagation delay + far end switching delay + upstream propagation delay] vs. [one way propagation delay]. > >I would compare BFD asynchronous mode to the use of continuity check (CC) cells and echo mode to the use of loopback cells in ATM. In general, loopback tests are useful as on demand tests for diagnosing faults (e.g. for locating a fault), but are not suitable as always on fault detection mechanisms. > >Regards, >Richard > > > From rtg-bfd-bounces@ietf.org Wed Aug 17 13:45:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5RyJ-0000Uw-0M; Wed, 17 Aug 2005 13:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5RyG-0000U3-IM for rtg-bfd@megatron.ietf.org; Wed, 17 Aug 2005 13:45:00 -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 NAA14160 for ; Wed, 17 Aug 2005 13:44:59 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5SXq-0006eR-4P for rtg-bfd@ietf.org; Wed, 17 Aug 2005 14:21:47 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D0CE1CC38E8 for ; Wed, 17 Aug 2005 10:44:47 -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 02630-02 for ; Wed, 17 Aug 2005 10:44:47 -0700 (PDT) Received: from trilobite.redback.com (trilobite.redback.com [155.53.42.154]) by prattle.redback.com (Postfix) with ESMTP id 7D036CC38E7 for ; Wed, 17 Aug 2005 10:44:47 -0700 (PDT) Received: from redback.com (localhost [127.0.0.1]) by trilobite.redback.com (8.11.6/8.8.8/null redback bsdclient) with ESMTP id j7HHil518542 for ; Wed, 17 Aug 2005 10:44:47 -0700 (PDT) Message-ID: <4303778F.1080304@redback.com> Date: Wed, 17 Aug 2005 10:44:47 -0700 From: Chezhian Renganathan User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.6) Gecko/20040127 X-Accept-Language: en MIME-Version: 1.0 To: rtg-bfd@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: draft-ietf-bfd-base-03.txt comments 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 Hello, Section 6.7.4 - Unless I am missing something, it seems to me that the statement in braces "roughly speaking, due to jitter" should be applicable in the context of Detection Time rather than DetectMult. The DetectMult is just number of packets and there is no variance there with jitter. Also, was there any thinking along the lines of making the "Reg Min Echo RX Interval" field optional, keeping with the spirit of this function, being optional with either modes. This field could potentially be set to all zeros for the entire length of a session unless changed if the end systems support this function. thanks, chez From rtg-bfd-bounces@ietf.org Wed Aug 17 14:41:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Sr0-0007nY-Lk; Wed, 17 Aug 2005 14:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Sqz-0007nT-Ir for rtg-bfd@megatron.ietf.org; Wed, 17 Aug 2005 14:41: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 OAA16695 for ; Wed, 17 Aug 2005 14:41:32 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5TQZ-00084G-J0 for rtg-bfd@ietf.org; Wed, 17 Aug 2005 15:18:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j7HIfM951351; Wed, 17 Aug 2005 11:41:22 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7HIfBG65451; Wed, 17 Aug 2005 11:41:11 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <4303778F.1080304@redback.com> References: <4303778F.1080304@redback.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 17 Aug 2005 11:41:08 -0700 To: Chezhian Renganathan X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: draft-ietf-bfd-base-03.txt comments 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 Aug 17, 2005, at 10:44 AM, Chezhian Renganathan wrote: > Hello, > > Section 6.7.4 - > Unless I am missing something, it seems to me that the statement in > braces > "roughly speaking, due to jitter" > should be applicable in the context of Detection Time rather than > DetectMult. > The DetectMult is just number of packets and there is no variance > there with > jitter. The text in the document is correct. DetectMult is used to calculate time, not count packets, so given the application of jitter, the number of packets missed is approximate (if DetectMult were 10, for example, the actual number of packets missed before detection might be as high as 13 if 25% jitter is applied and the timing is right.) > > Also, was there any thinking along the lines of making the "Reg Min > Echo RX > Interval" field optional, keeping with the spirit of this function, > being optional > with either modes. This field could potentially be set to all zeros > for the entire > length of a session unless changed if the end systems support this > function. Not sure exactly what you're saying here. To actually leave out the field and shorten the packet four bytes? I'm not sure what would be gained by this. The processing cost would be higher (Is the field there? What is the value?) and the difference in packet size negligible. As it stands now, the field can be set to zero if the sender does not wish or is not able to support the echo function. Perhaps I don't understand the question. --Dave > > thanks, > chez > > > From rtg-bfd-bounces@ietf.org Wed Aug 17 15:12:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TLB-000766-4v; Wed, 17 Aug 2005 15:12:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TL8-00075y-T0 for rtg-bfd@megatron.ietf.org; Wed, 17 Aug 2005 15:12:44 -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 PAA18558 for ; Wed, 17 Aug 2005 15:12:41 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Tuk-0000SG-0c for rtg-bfd@ietf.org; Wed, 17 Aug 2005 15:49:30 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9139CD545F8; Wed, 17 Aug 2005 12:12:33 -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 16366-09; Wed, 17 Aug 2005 12:12:33 -0700 (PDT) Received: from trilobite.redback.com (trilobite.redback.com [155.53.42.154]) by prattle.redback.com (Postfix) with ESMTP id 29395D545F6; Wed, 17 Aug 2005 12:12:33 -0700 (PDT) Received: from redback.com (localhost [127.0.0.1]) by trilobite.redback.com (8.11.6/8.8.8/null redback bsdclient) with ESMTP id j7HJCX518652; Wed, 17 Aug 2005 12:12:33 -0700 (PDT) Message-ID: <43038C20.7000102@redback.com> Date: Wed, 17 Aug 2005 12:12:32 -0700 From: Chezhian Renganathan User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.6) Gecko/20040127 X-Accept-Language: en MIME-Version: 1.0 To: Dave Katz References: <4303778F.1080304@redback.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: draft-ietf-bfd-base-03.txt comments 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 Dave Katz wrote: > > On Aug 17, 2005, at 10:44 AM, Chezhian Renganathan wrote: > >> Hello, >> >> Section 6.7.4 - >> Unless I am missing something, it seems to me that the statement in >> braces >> "roughly speaking, due to jitter" >> should be applicable in the context of Detection Time rather than >> DetectMult. >> The DetectMult is just number of packets and there is no variance >> there with >> jitter. > > > The text in the document is correct. DetectMult is used to calculate > time, not count packets, so given the application of jitter, the > number of packets missed is approximate (if DetectMult were 10, for > example, the actual number of packets missed before detection might > be as high as 13 if 25% jitter is applied and the timing is right.) > Ok got it. >> >> Also, was there any thinking along the lines of making the "Reg Min >> Echo RX >> Interval" field optional, keeping with the spirit of this function, >> being optional >> with either modes. This field could potentially be set to all zeros >> for the entire >> length of a session unless changed if the end systems support this >> function. > > > Not sure exactly what you're saying here. To actually leave out the > field and shorten the packet four bytes? I'm not sure what would be > gained by this. The processing cost would be higher (Is the field > there? What is the value?) and the difference in packet size > negligible. > Would it help the processing cost if done similar to the auth field which is controlled by the "A" flag.? Apart from reducing the overhead there is some bandwidth being saved too. For instance, when asynchronous mode is active across end systems (and potentially multiple sessions), with no echo support, with a 10 msecs tx interval, we could be sending these 4 bytes unnecessarily over the period of the session(s) uptime which could run into several days between interruptions. thanks, chez > As it stands now, the field can be set to zero if the sender does not > wish or is not able to support the echo function. > > Perhaps I don't understand the question. > > --Dave > >> >> thanks, >> chez >> >> >> > > From rtg-bfd-bounces@ietf.org Wed Aug 17 15:43:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Tom-0006Qi-KB; Wed, 17 Aug 2005 15:43:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Tol-0006Qd-EG for rtg-bfd@megatron.ietf.org; Wed, 17 Aug 2005 15:43:19 -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 PAA20780 for ; Wed, 17 Aug 2005 15:43:17 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5UOL-0001SY-VU for rtg-bfd@ietf.org; Wed, 17 Aug 2005 16:20:07 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7HJh8Bm069234; Wed, 17 Aug 2005 12:43:08 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7HJh8G78096; Wed, 17 Aug 2005 12:43:08 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <43038C20.7000102@redback.com> References: <4303778F.1080304@redback.com> <43038C20.7000102@redback.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0AE90888-5651-4272-8D0D-FF1536ADA3A4@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 17 Aug 2005 12:43:07 -0700 To: Chezhian Renganathan X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: draft-ietf-bfd-base-03.txt comments 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 > Would it help the processing cost if done similar to the auth field > which is controlled by the "A" flag.? > Apart from reducing the overhead there is some bandwidth being > saved too. For instance, when > asynchronous mode is active across end systems (and potentially > multiple sessions), > with no echo support, with a 10 msecs tx interval, we could be > sending these 4 bytes > unnecessarily over the period of the session(s) uptime which could > run into several days > between interruptions. The authentication stuff was made optional partly because of its size and complexity (there are environments in which it is unnecessary and would stand in the way of efficient implementation in silicon) and partly for backward compatibility (the authentication stuff was added later in the process.) The bandwidth savings is essentially invisible (it's totally invisible on Ethernet given the minimum packet size requirements.) Even at 10 msec intervals at 10Mbps it consumes only an additional . 03% of the bandwidth, if my math serves. Just not worth the trouble. --Dave From rtg-bfd-bounces@ietf.org Fri Aug 19 21:21:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6I2z-0000eI-W3; Fri, 19 Aug 2005 21:21:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6I2y-0000eD-Mn for rtg-bfd@megatron.ietf.org; Fri, 19 Aug 2005 21:21:20 -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 VAA16078 for ; Fri, 19 Aug 2005 21:21:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Id1-0006Ww-Mg for rtg-bfd@ietf.org; Fri, 19 Aug 2005 21:58:36 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6I2u-000MjI-9E for rtg-bfd@ietf.org; Sat, 20 Aug 2005 01:21:16 +0000 Date: Fri, 19 Aug 2005 18:21:08 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <102997400.20050819182108@psg.com> To: rtg-bfd@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: BFD UDP port assignments X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin 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 Folks- FYI, it seems that the port assignment IANA got doesn't quite correspond to what the specs say, and calls BFD Echo port "BFD-Control". From=20http://www.iana.org/assignments/port-numbers: > bfd 3784/tcp BFD > bfd 3784/udp BFD > # Dave Ward Dave Katz July 2003 > bfd-control 3785/tcp BFD-Control > bfd-control 3785/udp BFD-Control=20 > # Dave Ward Dave Katz July 2003 --=20 Alex http://www.psg.com/~zinin From rtg-bfd-bounces@ietf.org Tue Aug 23 22:25:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7kxM-0003pK-K9; Tue, 23 Aug 2005 22:25:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7kxK-0003ni-F0; Tue, 23 Aug 2005 22:25:34 -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 WAA25341; Tue, 23 Aug 2005 22:25:30 -0400 (EDT) Received: from usaga01-in.huawei.com ([63.250.163.245] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7kxS-0005tt-HS; Tue, 23 Aug 2005 22:25:47 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILP00HLBFW31A@usaga01-in.huawei.com>; Tue, 23 Aug 2005 19:21:39 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILP00CKNFW1SL@usaga01-in.huawei.com>; Tue, 23 Aug 2005 19:21:39 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [10.110.96.96]) by szxmc01-in.huawei.com (mshttpd); Wed, 24 Aug 2005 10:25:51 +0800 Date: Wed, 24 Aug 2005 10:25:51 +0800 From: yangpingan 30338 To: internet-drafts@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_77O+zUrE9Ek4bfnMa00vIw)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: rtg-bfd@ietf.org, jhaas@nexthop.com, dward@cisco.com, d.katz@juniper.com Subject: a draft about how BFD notifying the state change to applications 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. --Boundary_(ID_77O+zUrE9Ek4bfnMa00vIw) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT Dear all, I have written a draft about how BFD notifying the state change to applications, the purpose is to reduce the effect to system when BFD session goes up and down frequently, and reduce the packet loss when defect is recovered. It's 4 pages long, Comments are very welcome. Please help to post to the IETF website this draft and thank you for that. Thank you and Best regards. ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or em ail immediately and delete it! **************************************************************************************** --Boundary_(ID_77O+zUrE9Ek4bfnMa00vIw) Content-type: text/plain; NAME=draft-yz-bfd-WTR-HOLD-00.txt Content-disposition: attachment; filename=draft-yz-bfd-WTR-HOLD-00.txt Content-Transfer-Encoding: 7BIT Network Working Group Pingan Yang Internet Draft Huawei Techonologies Co., Ltd Suping Zhai Huawei Techonologies Co., Ltd Expires: February, 2006 August, 2005 WTR and HOLD process for BFD notifying the state change to applications draft-yz-bfd-WTR-HOLD-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes the WTR and HOLD processes of the Bidirectional Forwarding Detection (BFD) protocol when BFD notifies the state change to applications. Comments on this draft should be directed to rtg-bfd@ietf.org or to author directly. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. Pingan, Suping [Page 1] Internet Draft draft-yz-bfd-WTR-HOLD-00.txt August, 2005 1. Introduction BFD [BFD] provides a liveness detection mechanism that can be utilized by other network components for which their native liveness mechanisms are either too slow, inappropriate, or nonexistent. The drafts in BFD working group have detailed the use of BFD in specific situations ([BFD-1HOP], [BFD-MULTI], [BFD-MPLS], [BFD-GENERIC]). But there is no descriptions about how BFD notifying the state change to applications. This document describes the wait to restore(WTR) and HOLD processes when BFD notifying the state change to applications. When BFD session goes up or down, it should notify the associated applications. But in some environments the session may goes up and down frequently due to the transition path between the two systems. So before BFD notifying application we should apply some cushion mechanisms. When the path failures is recovered, it should make a delay before notifying forwarding engine, to ensure that the needed forwarding information(such as arp) is ok. Here we use the wait to restore(WTR) mechanism when BFD session goes up, and HOLD mechanism when BFD session goes down. 2. WTR Process When BFD session goes up, we start a WTR timer instead of notifying application immediately. We call the delay time Twtr. If the BFD session is still up when WTR timer times out, then notify application the session is up. Specially, zero delay time (Twtr = 0)means there is no need to perform WTR process, BFD will notify application immediately when BFD session goes up. 3. HOLD Process When BFD session goes down, we start a HOLD timer instead of notifying application immediately. We call the delay time Thold. If the BFD session is still down when HOLD timer times out, then notify application the session is down. Specially, zero delay time (Thold = 0)means there is no need to perform HOLD process, BFD will notify application immediately when BFD session goes down. Pingan, Suping [Page 2] Internet Draft draft-yz-bfd-WTR-HOLD-00.txt August, 2005 4. Interoperability and other Issues If WTR timer is running when BFD session goes down or HOLD timer is running when BFD session come up, we should solve the interoperability between WTR and HOLD. One way to accommodate this is: When BFD session goes up, if HOLD timer is running, then stop HOLD timer and does not notify application the state change of the session. Otherwise start WTR timer. When BFD session goes down, if WTR timer is running, then stop WTR timer and does not notify applications the session state change. Otherwise start Hold timer. The Thold and Twrt value may be negotiated when the BFD session setting up or can be independently configure/indicated by the applications. Normative References [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", draft-ietf-bfd-base-03.txt, July, 2005. [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single Hop)", draft-ietf-bfd-v4v6-1hop-03.txt, July, 2005. [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", draft-ietf-bfd-mpls-01.txt, February, 2005. [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- ietf-bfd-multihop-03.txt, July, 2005. [BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD", draft-ietf-bfd-generic-00.txt, July, 2005. [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Pingan, Suping [Page 3] Internet Draft draft-yz-bfd-WTR-HOLD-00.txt August, 2005 Security Considerations This specification does not raise any additional security issues beyond those of the specifications referred to in the list of normative references. Authors' Addresses Pingan Yang Huawei Technologies Co., LTD. No. 3 Xinxi Road, Shangdi, HaiDian District, Beijing City, The P.R.China Email: yangpingan@huawei.com Suping Zhai Huawei Technologies Co., LTD. No. 3 Xinxi Road, Shangdi, HaiDian District, Beijing City, The P.R.China Email: zhaisuping@huawei.com Full Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Pingan, Suping [Page 4] --Boundary_(ID_77O+zUrE9Ek4bfnMa00vIw)-- From rtg-bfd-bounces@ietf.org Wed Aug 24 07:22:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7tKn-00071V-Kn; Wed, 24 Aug 2005 07:22:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7tKl-0006wY-PN; Wed, 24 Aug 2005 07:22:19 -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 HAA13625; Wed, 24 Aug 2005 07:22:17 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7tL3-0004GF-4f; Wed, 24 Aug 2005 07:22:37 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 12:22:07 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Aug 2005 12:22:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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, 24 Aug 2005 12:22:06 +0100 Message-ID: Thread-Topic: a draft about how BFD notifying the state change to applications Thread-Index: AcWoUz9xPgAaSgrbQtKJNF24yQsInQAOt/BQ To: , X-OriginalArrivalTime: 24 Aug 2005 11:22:07.0258 (UTC) FILETIME=[0FC1B7A0:01C5A89E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org, jhaas@nexthop.com, dward@cisco.com, d.katz@juniper.com Subject: RE: a draft about how BFD notifying the state change to applications 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 Pingan, If I understand correctly, the problem you are trying to solve is the = case where we get a flapping BFD session (i.e. the session is going up = and down repeatedly), e.g. due to an intermittent link failure. Your = solution is to use hold timers to delay any actions to be taken by = applications as a result of a session going up or down. IMO your solution does not solve the problem. If a session is flapping = then the flapping needs to be detected and the appropriate action taken. = Your solution does not reliably detect flapping and I assume is based on = ignoring flaps that occur within the configured hold times. The current text in section 4 states: "When BFD session goes up, if HOLD = timer is running, then stop HOLD timer and does not notify application = the state change of the session. Otherwise start WTR timer." The effect = of this proposal is that when you get a BFD session going up and down, = although it will be detected by BFD, the application will never take any = action if the flap interval is less than the hold timer. For example, = lets say the flap interval is 5secs and the hold timer is set to 10secs. = When the session goes down the hold timer will start but after 5 secs = the session will come back up and the hold timer will be stopped and no = action taken. This cycle will continue indefinitely, i.e. traffic will = continue to be dropped intermittently and the flapping will not be = detected. Even if you don't stop the hold timer when the session comes back up, = you still won't reliably detect flapping. Lets say a session goes down = and you start the hold timer (set to say 10 secs). The session might go = up and down 5 times during the 10 sec hold time, but by chance when the = hold timer expires the session may be up. In which case, the application = won't take any action despite traffic being lost intermittently over the = 10 sec period. Also, the main purpose of using BFD is to provide fast fault detection. = If hold timers are introduced to delay any actions to be taken following = fault detection (e.g. failover to a backup route), then what's the point = of having fast detection in the first place? An alternative solution would be to use a BFD session up/down state = transition alarm threshold. If the number of times a session goes = up/down within a configured time period exceeds the threshold, then the = session can i) be disabled or administratively shut down (under control = of OSS or the BFD system itself), ii) an alarm raised to instigate fault = diagnosis/correction activities, or iii) both. This solution does not = require any changes to the BFD protocol and could be implemented today. Regards, Richard > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On > Behalf Of yangpingan 30338 > Sent: 24 August 2005 03:26 > To: internet-drafts@ietf.org > Cc: rtg-bfd@ietf.org; jhaas@nexthop.com; dward@cisco.com; > d.katz@juniper.com > Subject: a draft about how BFD notifying the state change to > applications >=20 >=20 >=20 > Dear all, >=20 > I have written a draft about how BFD notifying the state=20 > change to applications, the purpose is to reduce the effect to system > when BFD session goes up and down frequently, and reduce the=20 > packet loss when defect is recovered. It's 4 pages long,=20 > Comments are very welcome. >=20 > Please help to post to the IETF website this draft and thank=20 > you for that. >=20 >=20 > Thank you and Best regards. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ************************************************************** > **************************** > This email and its attachments contain confidential=20 > information from HUAWEI, which is intended only for the=20 > person or entity whose address is listed above. Any use of=20 > the information contained herein in any way (including, but=20 > not limited to, total or partial disclosure, reproduction, or=20 > dissemination) by persons other than the intended=20 > recipient(s) is prohibited. If you receive this e-mail in=20 > error, please notify the sender by phone or em > ail immediately and delete it! > =20 > ************************************************************** > ************************** >=20 From rtg-bfd-bounces@ietf.org Wed Aug 24 09:52:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7vfd-0000ch-6C; Wed, 24 Aug 2005 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7vfb-0000cV-Od; Wed, 24 Aug 2005 09:51: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 JAA21376; Wed, 24 Aug 2005 09:51:56 -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 1E7vfh-0000ow-BL; Wed, 24 Aug 2005 09:52:18 -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 <0ILQ000TTC5U7T@szxga02-in.huawei.com>; Wed, 24 Aug 2005 21:58:42 +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 <0ILQ00LNUC5U2Y@szxga02-in.huawei.com>; Wed, 24 Aug 2005 21:58:42 +0800 (CST) Received: from qingyuan64202 ([221.216.175.92]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILQ00BWNCA9L0@szxml01-in.huawei.com>; Wed, 24 Aug 2005 22:01:47 +0800 (CST) Date: Wed, 24 Aug 2005 21:57:24 +0800 From: Yang Pingan To: richard.spencer@bt.com, internet-drafts@ietf.org Message-id: <001901c5a8b3$e7c1d760$6607fea9@qingyuan64202> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7BIT Cc: rtg-bfd@ietf.org, jhaas@nexthop.com, dward@cisco.com, d.katz@juniper.com Subject: Re: a draft about how BFD notifying the state change to applications 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 Richard, What you said is just one possible situation of WTR and HOLD process. Normally the hold time is less than WTR time(The recommended value of HOLD timer is several seconds or less than one second. and WTR timer several minute). So this cannot be achieved by alarm threshold. And another purpose of WTR is that: before BFD notifying forwarding engine, it gives the chance for preparing forwarding table(especially for 1hop BFD), so can avoid traffic lost when defect is recoverd. ----- Original Message ----- From: To: ; Cc: ; ; ; Sent: Wednesday, August 24, 2005 7:22 PM Subject: RE: a draft about how BFD notifying the state change to applications Pingan, If I understand correctly, the problem you are trying to solve is the case where we get a flapping BFD session (i.e. the session is going up and down repeatedly), e.g. due to an intermittent link failure. Your solution is to use hold timers to delay any actions to be taken by applications as a result of a session going up or down. IMO your solution does not solve the problem. If a session is flapping then the flapping needs to be detected and the appropriate action taken. Your solution does not reliably detect flapping and I assume is based on ignoring flaps that occur within the configured hold times. The current text in section 4 states: "When BFD session goes up, if HOLD timer is running, then stop HOLD timer and does not notify application the state change of the session. Otherwise start WTR timer." The effect of this proposal is that when you get a BFD session going up and down, although it will be detected by BFD, the application will never take any action if the flap interval is less than the hold timer. For example, lets say the flap interval is 5secs and the hold timer is set to 10secs. When the session goes down the hold timer will start but after 5 secs the session will come back up and the hold timer will be stopped and no action taken. This cycle will continue indefinitely, i.e. traffic will continue to be dropped intermittently and the flapping will not be detected. Even if you don't stop the hold timer when the session comes back up, you still won't reliably detect flapping. Lets say a session goes down and you start the hold timer (set to say 10 secs). The session might go up and down 5 times during the 10 sec hold time, but by chance when the hold timer expires the session may be up. In which case, the application won't take any action despite traffic being lost intermittently over the 10 sec period. Also, the main purpose of using BFD is to provide fast fault detection. If hold timers are introduced to delay any actions to be taken following fault detection (e.g. failover to a backup route), then what's the point of having fast detection in the first place? An alternative solution would be to use a BFD session up/down state transition alarm threshold. If the number of times a session goes up/down within a configured time period exceeds the threshold, then the session can i) be disabled or administratively shut down (under control of OSS or the BFD system itself), ii) an alarm raised to instigate fault diagnosis/correction activities, or iii) both. This solution does not require any changes to the BFD protocol and could be implemented today. Regards, Richard > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On > Behalf Of yangpingan 30338 > Sent: 24 August 2005 03:26 > To: internet-drafts@ietf.org > Cc: rtg-bfd@ietf.org; jhaas@nexthop.com; dward@cisco.com; > d.katz@juniper.com > Subject: a draft about how BFD notifying the state change to > applications > > > > Dear all, > > I have written a draft about how BFD notifying the state > change to applications, the purpose is to reduce the effect to system > when BFD session goes up and down frequently, and reduce the > packet loss when defect is recovered. It's 4 pages long, > Comments are very welcome. > > Please help to post to the IETF website this draft and thank > you for that. > > > Thank you and Best regards. > > > > > > > > > > > > > > > > > > ************************************************************** > **************************** > This email and its attachments contain confidential > information from HUAWEI, which is intended only for the > person or entity whose address is listed above. Any use of > the information contained herein in any way (including, but > not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in > error, please notify the sender by phone or em > ail immediately and delete it! > > ************************************************************** > ************************** > From rtg-bfd-bounces@ietf.org Wed Aug 24 12:46:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yOG-0001Bg-5Z; Wed, 24 Aug 2005 12:46:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yO5-00017c-As; Wed, 24 Aug 2005 12:46:06 -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 MAA03583; Wed, 24 Aug 2005 12:46:01 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7yOP-00078c-Sv; Wed, 24 Aug 2005 12:46:26 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2005 12:45:55 -0400 X-IronPort-AV: i="3.96,138,1122868800"; d="scan'208"; a="67705032:sNHT34652364" Received: from [10.83.15.50] (rtp-tnadeau-vpn1.cisco.com [10.83.15.50]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j7OGjpT7018746; Wed, 24 Aug 2005 12:45:52 -0400 (EDT) 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: "Thomas D. Nadeau" Date: Wed, 24 Aug 2005 12:45:44 -0400 To: richard.spencer@bt.com X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: jhaas@nexthop.com, dward@cisco.com, rtg-bfd@ietf.org, internet-drafts@ietf.org, yangpingan@huawei.com, d.katz@juniper.com Subject: Re: a draft about how BFD notifying the state change to applications 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 Good analysis Richard. One comment below. > Pingan, > > If I understand correctly, the problem you are trying to solve is > the case where we get a flapping BFD session (i.e. the session is > going up and down repeatedly), e.g. due to an intermittent link > failure. Your solution is to use hold timers to delay any actions > to be taken by applications as a result of a session going up or down. > > IMO your solution does not solve the problem. If a session is > flapping then the flapping needs to be detected and the appropriate > action taken. Your solution does not reliably detect flapping and I > assume is based on ignoring flaps that occur within the configured > hold times. > > The current text in section 4 states: "When BFD session goes up, if > HOLD timer is running, then stop HOLD timer and does not notify > application the state change of the session. Otherwise start WTR > timer." The effect of this proposal is that when you get a BFD > session going up and down, although it will be detected by BFD, the > application will never take any action if the flap interval is less > than the hold timer. For example, lets say the flap interval is > 5secs and the hold timer is set to 10secs. When the session goes > down the hold timer will start but after 5 secs the session will > come back up and the hold timer will be stopped and no action > taken. This cycle will continue indefinitely, i.e. traffic will > continue to be dropped intermittently and the flapping will not be > detected. > > Even if you don't stop the hold timer when the session comes back > up, you still won't reliably detect flapping. Lets say a session > goes down and you start the hold timer (set to say 10 secs). The > session might go up and down 5 times during the 10 sec hold time, > but by chance when the hold timer expires the session may be up. In > which case, the application won't take any action despite traffic > being lost intermittently over the 10 sec period. > > Also, the main purpose of using BFD is to provide fast fault > detection. If hold timers are introduced to delay any actions to be > taken following fault detection (e.g. failover to a backup route), > then what's the point of having fast detection in the first place? > > An alternative solution would be to use a BFD session up/down state > transition alarm threshold. If the number of times a session goes > up/down within a configured time period exceeds the threshold, then > the session can i) be disabled or administratively shut down (under > control of OSS or the BFD system itself), ii) an alarm raised to > instigate fault diagnosis/correction activities, or iii) both. This > solution does not require any changes to the BFD protocol and could > be implemented today. Based on the premise that BFD should allow for fast detection, I think you are right here in that all of the raw alarms should be forwarded to the applications that are interested in those alarms. This is indeed how the various implementations that I am familiar with do this. It is a local decision as to how to process (i.e.: squelch/forward/aggregate) those alarms. It doesn't seem under the purview of the BFD protocol however, to stipulate how the alarms are processed given this point. Also another important point to include is that different applications may need different processing algorithms, which also makes this something too application specific to be stipulated as part of the BFD protocol. --Tom > > Regards, > Richard > > >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On >> Behalf Of yangpingan 30338 >> Sent: 24 August 2005 03:26 >> To: internet-drafts@ietf.org >> Cc: rtg-bfd@ietf.org; jhaas@nexthop.com; dward@cisco.com; >> d.katz@juniper.com >> Subject: a draft about how BFD notifying the state change to >> applications >> >> >> >> Dear all, >> >> I have written a draft about how BFD notifying the state >> change to applications, the purpose is to reduce the effect to system >> when BFD session goes up and down frequently, and reduce the >> packet loss when defect is recovered. It's 4 pages long, >> Comments are very welcome. >> >> Please help to post to the IETF website this draft and thank >> you for that. >> >> >> Thank you and Best regards. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ************************************************************** >> **************************** >> This email and its attachments contain confidential >> information from HUAWEI, which is intended only for the >> person or entity whose address is listed above. Any use of >> the information contained herein in any way (including, but >> not limited to, total or partial disclosure, reproduction, or >> dissemination) by persons other than the intended >> recipient(s) is prohibited. If you receive this e-mail in >> error, please notify the sender by phone or em >> ail immediately and delete it! >> >> ************************************************************** >> ************************** >> > From rtg-bfd-bounces@ietf.org Wed Aug 24 13:41:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zFj-0004rQ-Of; Wed, 24 Aug 2005 13:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zFg-0004rL-GO for rtg-bfd@megatron.ietf.org; Wed, 24 Aug 2005 13:41:29 -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 NAA07393 for ; Wed, 24 Aug 2005 13:41:27 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zG2-0000uO-K2 for rtg-bfd@ietf.org; Wed, 24 Aug 2005 13:41:51 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 18:41:18 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Aug 2005 18:41:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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, 24 Aug 2005 18:41:17 +0100 Message-ID: Thread-Topic: a draft about how BFD notifying the state change to applications Thread-Index: AcWosu7ePL6jDt2fTfu5lz9HNLQuAAABvVTg To: X-OriginalArrivalTime: 24 Aug 2005 17:41:18.0098 (UTC) FILETIME=[08506720:01C5A8D3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org Subject: RE: a draft about how BFD notifying the state change to applications 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 Pingan, Perhaps it would help to understand what the perceived benefits of your = solution are if you could provide some example applications with details = of how it would work? Please see further comments in line... > Richard, >=20 > What you said is just one possible situation of WTR and HOLD=20 > process. Yes, that's why I said it was an example. > Normally the hold time is less than WTR time(The recommended > value of HOLD timer is several seconds or less than one=20 > second. and WTR timer several minute). It doesn't matter what you set the HOLD time to, (unless you set it to = zero) you are still negating the benefits of fast fault detection. = Regarding the WTR timer, other than addressing the issue of flapping = sessions (which IMO your solution doesn't do anyway) what do you believe = the benefits of using this timer are? IMO it raises more issues than it = solves. For example, performance monitoring should only be performed = when a link/LSP/route is available. In your proposal you would need to = start measuring performance when the WTR timer expires, don't you think = this will have an adverse effect on meeting SLAs?, i.e. outages will be = longer (and more expensive to the operator) than they need to be. As = another example, what if you are using an expensive ISDN dialup circuit = for the backup path, wouldn't you want to switch back over to the = primary (e.g. leased line) circuit as soon as possible to avoid = unnecessary dialup charges? > So this cannot be achieved by alarm threshold. If you are referring here to the ability to wait for a user configurable = period of time before sending the BFD status to an application then yes = you are correct, using an alarm threshold doesn't provide this ability. = However, that's not the intention, the purpose of the threshold as I = described would be to detect session flapping in order to take the = appropriate action (similar to the way in which BGP route dampening = works). As I said previously, I can't think of any benefits of using a = WTR timer and the HOLD timer negates the benefits of fast detection. > And another purpose of WTR is that: before BFD notifying=20 > forwarding engine, it gives the chance for preparing=20 > forwarding table(especially for 1hop BFD), Exactly what preparation do you believe can/should be done while waiting = for the WTR timer to expire? > so can avoid traffic lost when defect is recovered. Why do you believe traffic will be lost when a defect is recovered from? = If there is no backup for the failed LSP/route/link then any traffic = being sent is going to be lost anyway until the defect is recovered = from. If traffic is currently using a backup LSP/route/link then why do = you think traffic will be lost when the defect is recovered from and the = primary becomes available? For example, in the backup static IP route case, once a BFD session = associated with a primary static IP route comes back up then the router = can simply stop forwarding using the backup route and start using the = primary. You mention ARP in your draft, but IMO this shouldn't be a = problem. BFD systems connected via Ethernet need ARP cache entries = associated with the next hops they use to reach each other before they = can send BFD control packets. The ARP cache entry for a primary static = IP route next-hop must already be in the ARP cache by the time the BFD = session comes back up, and therefore no user traffic using the static = route should be lost. Lets take OSPF as another example, why would you want to wait a period = of time (i.e. the WTR time) before re-establishing an OSPF adjacency or = re-advertising routes to an OSPF neighbour that has become reachable? = You can't send any IP traffic to a neighbour until you've exchanged = routes anyway. So, as with the previous static route example, if there = is no alternative route you're dropping packets anyway, if there is an = alternative route then you will continue use the alternative until = you've exchanged LSAs and learned alterative routes with a shorter path. Regards, Richard > ----- Original Message -----=20 > From: > To: ; > Cc: ; ;=20 > ; > Sent: Wednesday, August 24, 2005 7:22 PM > Subject: RE: a draft about how BFD notifying the state change=20 > to applications >=20 >=20 > Pingan, >=20 > If I understand correctly, the problem you are trying to=20 > solve is the case where we get a flapping BFD session (i.e.=20 > the session is going up and down repeatedly), e.g. due to an=20 > intermittent link failure. Your solution is to use hold=20 > timers to delay any actions to be taken by applications as a=20 > result of a session going up or down. >=20 > IMO your solution does not solve the problem. If a session is=20 > flapping then the flapping needs to be detected and the=20 > appropriate action taken. Your solution does not reliably=20 > detect flapping and I assume is based on ignoring flaps that=20 > occur within the configured hold times. >=20 > The current text in section 4 states: "When BFD session goes=20 > up, if HOLD timer is running, then stop HOLD timer and does=20 > not notify application the state change of the session.=20 > Otherwise start WTR timer." The effect of this proposal is=20 > that when you get a BFD session going up and down, although=20 > it will be detected by BFD, the application will never take=20 > any action if the flap interval is less than the hold timer.=20 > For example, lets say the flap interval is 5secs and the hold=20 > timer is set to 10secs. When the session goes down the hold=20 > timer will start but after 5 secs the session will come back=20 > up and the hold timer will be stopped and no action taken.=20 > This cycle will continue indefinitely, i.e. traffic will=20 > continue to be dropped intermittently and the flapping will=20 > not be detected. >=20 > Even if you don't stop the hold timer when the session comes=20 > back up, you still won't reliably detect flapping. Lets say a=20 > session goes down and you start the hold timer (set to say 10=20 > secs). The session might go up and down 5 times during the 10=20 > sec hold time, but by chance when the hold timer expires the=20 > session may be up. In which case, the application won't take=20 > any action despite traffic being lost intermittently over the=20 > 10 sec period. >=20 > Also, the main purpose of using BFD is to provide fast fault=20 > detection. If hold timers are introduced to delay any actions=20 > to be taken following fault detection (e.g. failover to a=20 > backup route), then what's the point of having fast detection=20 > in the first place? >=20 > An alternative solution would be to use a BFD session up/down=20 > state transition alarm threshold. If the number of times a=20 > session goes up/down within a configured time period exceeds=20 > the threshold, then the session can i) be disabled or=20 > administratively shut down (under control of OSS or the BFD=20 > system itself), ii) an alarm raised to instigate fault=20 > diagnosis/correction activities, or iii) both. This solution=20 > does not require any changes to the BFD protocol and could be=20 > implemented today. >=20 > Regards, > Richard >=20 > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On > > Behalf Of yangpingan 30338 > > Sent: 24 August 2005 03:26 > > To: internet-drafts@ietf.org > > Cc: rtg-bfd@ietf.org; jhaas@nexthop.com; dward@cisco.com; > > d.katz@juniper.com > > Subject: a draft about how BFD notifying the state change to > > applications > >=20 > >=20 > >=20 > > Dear all, > >=20 > > I have written a draft about how BFD notifying the state=20 > > change to applications, the purpose is to reduce the effect=20 > to system > > when BFD session goes up and down frequently, and reduce the=20 > > packet loss when defect is recovered. It's 4 pages long,=20 > > Comments are very welcome. > >=20 > > Please help to post to the IETF website this draft and thank=20 > > you for that. > >=20 > >=20 > > Thank you and Best regards. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > ************************************************************** > > **************************** > > This email and its attachments contain confidential=20 > > information from HUAWEI, which is intended only for the=20 > > person or entity whose address is listed above. Any use of=20 > > the information contained herein in any way (including, but=20 > > not limited to, total or partial disclosure, reproduction, or=20 > > dissemination) by persons other than the intended=20 > > recipient(s) is prohibited. If you receive this e-mail in=20 > > error, please notify the sender by phone or em > > ail immediately and delete it! > > =20 > > ************************************************************** > > ************************** > > >=20 From rtg-bfd-bounces@ietf.org Wed Aug 24 13:45:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zJO-0006UG-2q; Wed, 24 Aug 2005 13:45:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zJM-0006U3-0H for rtg-bfd@megatron.ietf.org; Wed, 24 Aug 2005 13:45:16 -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 NAA07836 for ; Wed, 24 Aug 2005 13:45:11 -0400 (EDT) Received: from gateout01.mbox.net ([165.212.64.21] helo=gwo1.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zJb-00015a-Tr for rtg-bfd@ietf.org; Wed, 24 Aug 2005 13:45:35 -0400 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gwo1.mbox.net (Postfix) with SMTP id 0B07312DC63 for ; Wed, 24 Aug 2005 17:44:29 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.17K) with ESMTP id 317JHXRSb0094Mo1; Wed, 24 Aug 2005 17:44:28 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.17K) with ESMTP id 314JHXRSA0094Mo1; Wed, 24 Aug 2005 17:44:26 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.21U); Wed, 24 Aug 2005 17:44:26 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID002JHXRSA6754Xo1 Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 11:44:26 -0600 Date: Wed, 24 Aug 2005 13:44:25 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Message-ID: <20050824174425.GP18869@nexthop.com> References: <001901c5a8b3$e7c1d760$6607fea9@qingyuan64202> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001901c5a8b3$e7c1d760$6607fea9@qingyuan64202> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 24 Aug 2005 17:44:26.0440 (UTC) FILETIME=[78931C80:01C5A8D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: Re: a draft about how BFD notifying the state change to applications 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, Aug 24, 2005 at 09:57:24PM +0800, Yang Pingan wrote: > And another purpose of WTR is that: before BFD notifying forwarding engine, I think this is one of the key phrases. BFD need not "notify the forwarding engine". One's system can be designed to notify whatever component is appropriate. The raw "session transitioned up", "session transitioned down" events can be passed to whatever component you like. If you wish to damp behavior of those applications, you could apply your mechanism and provide an intermediate layer between BFD and your application. I wonder, based on your example, whether or not a different use of BFD may be more appropriate. If you're using BFD in conjuction with some sort of failover/high availability mechanism, you have two pieces of information that you are concerned about: - If you are verifying connectivity to a given instance of some application. - You are verifying that forwarding works to this instance. To give a more concrete example, if you are using BFD for static routes where the nexthop is a nexthop managed by VRRP, there may be a forwarding failure to the nexthop. At some point determined by VRRP configuration and state, another VRRP host will take over. If, in this example, you wished to monitor forwarding, BFD to the VRRP nexthop may be appropriate. However, the timers probably should be such that the BFD timeout is higher than the VRRP failover time. If you wish to monitor a given VRRP host, your BFD session should be to an address other than the VRRP virtual address. My apologies if this example misses your point. -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Tue Aug 30 04:47:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA1lx-0003f5-PW; Tue, 30 Aug 2005 04:47:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA1lw-0003f0-UB for rtg-bfd@megatron.ietf.org; Tue, 30 Aug 2005 04:47: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 EAA29401 for ; Tue, 30 Aug 2005 04:47:10 -0400 (EDT) Received: from nproxy.gmail.com ([64.233.182.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA1nR-0001mO-Ll for rtg-bfd@ietf.org; Tue, 30 Aug 2005 04:48:46 -0400 Received: by nproxy.gmail.com with SMTP id x4so348736nfb for ; Tue, 30 Aug 2005 01:46:59 -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=Z+x0+bJMVhnsynRjE64L+MGqppQvp61nHg8kt3l1heiYMUhE9QVoGr/kus/kMZzggf1QLLYZgX3Ua+R9gv8NjdbbNHgzbGUOpSqWvA+YICS/rQ8upqdbcDwNjwm1jLnqEyFaqTEHsL3+WbqNM7nT9dK9w0SMjhvxrgca3nb1iqk= Received: by 10.48.1.14 with SMTP id 14mr332360nfa; Tue, 30 Aug 2005 01:46:59 -0700 (PDT) Received: by 10.48.247.17 with HTTP; Tue, 30 Aug 2005 01:46:59 -0700 (PDT) Message-ID: <9e31186f050830014627aff97d@mail.gmail.com> Date: Tue, 30 Aug 2005 10:46:59 +0200 From: Carlos Garcia Braschi To: rtg-bfd@ietf.org In-Reply-To: <42fcbf72.7c98d4c4.641f.0bfdSMTPIN_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: <42fcbf72.7c98d4c4.641f.0bfdSMTPIN_ADDED@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Subject: IETF 63 agreements 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, Rereading the IETF 63 minutes, I have some doubts about what was agreed the= re:=20 Dave said that applications would be inlined in the text of the generic applications draft, but I am not sure if the applications would be the ones that are now there (static routes), or others like BGP or RIP would be added. Are the slides from Suping archived somewhere? In the minutes Pekka refers to the first bullet point of the presentation but it is not clear from the context what is it about. On the generic draft, something that worries me is the problem of having multiple peers in a client application (broadcast subnets with many peers, it happens in Nework PoPs and Ethernet Access networks or BGP peering points), some that support BFD and some that don't. Figuring out which ones do and which ones don't is something not trivial: it either requires configuration (work for the network operators, and may not even be feasible if there are many peers), or protocol work to signal it. So the current recommended approach (if I get it right) is to just let the BFD session never reach the Up state, and as in the Down state it only has to transmit at the sedate rate, it may not be that great of a problem. Should a mention about this be added to the generic application draft or is it too obvious? I don't know if even the sedate rate can cause problems for some systems (1p/s can cause some load, depending on the implementation and number of peers). Given that a router should respond with an ICMP port unreachable to BFD packets if it does not implement BFD (although it may not due to security purposes, it would be required per the host requirements standard), could this be taken as a sign of non-implementation that causes packets not to be sent? (for example, on receipt take a passive role and enter the AdminDown state). Regards, Carlos. -- Telefonica Empresas.