From rtg-bfd-bounces@ietf.org Wed Mar 07 15:51:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36B-0002PL-QF; Wed, 07 Mar 2007 15:50:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35O-0001OG-Vu; Wed, 07 Mar 2007 15:50:11 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP35L-0001QG-Fl; Wed, 07 Mar 2007 15:50:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 02EBD26ECE; Wed, 7 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35G-00030g-LM; Wed, 07 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-generic-03.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: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Generic Application of BFD Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-generic-03.txt Pages : 16 Date : 2007-3-7 This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-generic-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-generic-03.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: <2007-3-7121620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-generic-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-generic-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7121620.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Mar 07 15:51:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP364-0002H0-OD; Wed, 07 Mar 2007 15:50:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35O-0001Ns-9m; Wed, 07 Mar 2007 15:50:10 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP35K-0001Pw-VQ; Wed, 07 Mar 2007 15:50:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id DBA3032ACC; Wed, 7 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35G-00030m-NN; Wed, 07 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-multihop-05.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: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for Multihop Paths Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-multihop-05.txt Pages : 7 Date : 2007-3-7 This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-05.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-multihop-05.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-multihop-05.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: <2007-3-7121750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-multihop-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-multihop-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7121750.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Mar 07 15:51:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP360-0002Ai-06; Wed, 07 Mar 2007 15:50:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35N-0001Nb-R9; Wed, 07 Mar 2007 15:50:09 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP35K-0001Pv-Tb; Wed, 07 Mar 2007 15:50:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B9B8B32ACA; Wed, 7 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35G-00030a-Jp; Wed, 07 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-06.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: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for IPv4 and IPv6 (Single Hop) Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-v4v6-1hop-06.txt Pages : 8 Date : 2007-3-7 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-v4v6-1hop-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-06.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: <2007-3-7121439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7121439.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Mar 07 15:51:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35w-000236-0o; Wed, 07 Mar 2007 15:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35N-0001NJ-D8; Wed, 07 Mar 2007 15:50:09 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP35K-0001PK-II; Wed, 07 Mar 2007 15:50:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id AA82E32AC4; Wed, 7 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35G-00030U-IS; Wed, 07 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-base-06.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: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Bidirectional Forwarding Detection Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-base-06.txt Pages : 48 Date : 2007-3-7 This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-base-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-base-06.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: <2007-3-7121311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-base-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-base-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7121311.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Fri Mar 09 04:04:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb0W-0008SE-KX; Fri, 09 Mar 2007 04:03:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPaK-0000CF-04; Thu, 08 Mar 2007 15:51:36 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPaJ-0002IY-Df; Thu, 08 Mar 2007 15:51:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9391B1782A; Thu, 8 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYq-0007IZ-Ak; Thu, 08 Mar 2007 15:50:04 -0500 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, 08 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-mpls-04.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD For MPLS LSPs Author(s) : R. Aggarwal, et al. Filename : draft-ietf-bfd-mpls-04.txt Pages : 12 Date : 2007-3-8 One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a MPLS LSP data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mpls-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-mpls-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-mpls-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8131025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-mpls-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-mpls-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8131025.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Fri Mar 30 13:22:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKnL-0005HB-V7; Fri, 30 Mar 2007 13:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKnK-0005Gz-Oa for rtg-bfd@ietf.org; Fri, 30 Mar 2007 13:21:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKnJ-0002Iy-CF for rtg-bfd@ietf.org; Fri, 30 Mar 2007 13:21:46 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2007 10:21:44 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2UHLiR6004478 for ; Fri, 30 Mar 2007 10:21:44 -0700 Received: from [128.107.98.28] ([128.107.98.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2UHLiwn015157 for ; Fri, 30 Mar 2007 17:21:44 GMT Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> Content-Transfer-Encoding: 7bit From: Naiming Shen Date: Fri, 30 Mar 2007 10:21:43 -0700 To: rtg-bfd@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2784; t=1175275304; x=1176139304; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Fwd=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20; bh=qxz7fqlf+zozKvyMsOUCiHGCFSEzjziKUE+pz6QUlBM=; b=CMuGyad6jfpWMK1AhWiNX/L5KL5w7y6tm10OrlXvnqm4VUqI4ROhQsW4lmGwx5/kG/LFYZj0 MicTY5AWWWU1+Dnzd1CWFM5xl0jehGiQshx4x1Mjvb7rpMZupaj+O4yUoOyelNgRc9IUsdJrBO qBa8OKEVhk/L4aA9TF9lIFgaU=; Authentication-Results: sj-dkim-1; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: Fwd: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.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: , Errors-To: rtg-bfd-bounces@ietf.org hi bfd-wg, comments are welcome. thanks. - Naiming Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 28, 2007 12:50:02 PM PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Interface Based Point-to-Point Neighbor BFD > Author(s) : N. Shen > Filename : draft-shen-bfd-intf-p2p-nbr-00.txt > Pages : 7 > Date : 2007-3-28 > > This document describes an application of Bidirectional Forwarding > Detection (BFD) protocol named Interface Based Point-to-Point > Neighbor BFD. This mechanism can be used to simplify the BFD > operations over point-to-point physical and logical links in > networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shen-bfd-intf-p2p-nbr-00.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-shen-bfd-intf-p2p-nbr-00.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-shen-bfd-intf-p2p-nbr-00.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. > Content-Type: text/plain > Content-ID: <2007-3-28100539.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From rtg-bfd-bounces@ietf.org Fri Mar 30 17:45:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXOu4-0000KQ-1l; Fri, 30 Mar 2007 17:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXOu3-0000KF-Da for rtg-bfd@ietf.org; Fri, 30 Mar 2007 17:44:59 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXOu2-0001Mt-3S for rtg-bfd@ietf.org; Fri, 30 Mar 2007 17:44:59 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 30 Mar 2007 14:44:57 -0700 X-IronPort-AV: i="4.14,355,1170662400"; d="scan'208"; a="679061718:sNHT42033920" 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 l2ULiuJ26424; Fri, 30 Mar 2007 14:44:56 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> Content-Transfer-Encoding: quoted-printable From: Dave Katz Date: Fri, 30 Mar 2007 14:44:56 -0700 To: Naiming Shen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.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: , Errors-To: rtg-bfd-bounces@ietf.org Hi Naiming, thanks for submitting this. I've pointed out privately to Naiming that I think this is a rather =20 ugly architectural hack, albeit a pragmatic one. The Right Way=99 to =20= do this would be to run BFD directly over the datalink layer and take =20= down all data protocols (but not the datalink) in sympathy with the =20 BFD session state. However, there are (at least) two problems with =20 this. Firstly, it means specifying how to run BFD over a plethora of =20= datalink layers. Secondly, the IETF cannot standardize how to run =20 BFD over datalink layers it does not control (so we could standardize =20= something directly over PPP, for example, but not IEEE or cisco HDLC.) The architectural ugliness, aside from being a layer violation, rears =20= its head in a couple of ways related to fate-sharing. Firstly, it =20 means that everything shares fate with the IP over which BFD is being =20= run, so if, say, IPv4 forwarding fails, non-v4 applications will see =20 the failure. This isn't *too* terrible; it means that there may be =20 false negatives, causing the application to temporarily flap. But secondly, there is a self-referential problem. What you'd =20 *really* like to do on a BFD failure is to take down the failing =20 protocol and keep it down until the BFD session resumes. But you =20 can't do this if BFD is running on top of that failing protocol =20 (which it will be) which thus requires the "special flag" hack and =20 only temporarily taking down the protocol. The fate-sharing =20 implications of this are more serious, because it is possible to get =20 false positives in some cases when the data protocol has failed. =20 Imagine, for example, running ISIS with this method. If IPv4 fails, =20 the BFD session goes down, the interface flaps for five seconds, and =20 then is reenabled. At that point ISIS will happily come back up and =20 report IP reachability even though it doesn't exist. You can bet =20 that folks who have not yet implemented BFD will be tempted to do this. My other objection to the "special flag" is that it is arguably =20 overspecified. As far as I can tell, this is isomorphic with simply =20 having static routes interact with BFD "directly" and is already =20 covered by the generic spec (which carefully says only what the =20 effect of the interaction should be, not the implementation of it.) =20 It is an explicit signaling mechanism from BFD, albeit a primitive one. In light of this, my preference would be for all of the verbiage =20 about static routes and dynamic protocols and special fiags to be =20 removed. In place of this, add text that is very specific about the =20 fate-sharing implications of this mechanism as outlined above, and =20 point out that any application of BFD that does not automatically =20 share fate with the data protocol over which BFD is running (such as =20 ISIS or static routes) MUST have some form of explicit interaction =20 with BFD in order to avoid false positives, and leave it at that. =20 The "special bit" hack is orthogonal to this mechanism; it could =20 just as well have been specified in the generic spec (and would have =20 been just as inappropriate there.) It would be nice to point out that the only function of flapping the =20 interface is to provide an Up->Down edge for protocols to see, and =20 that the only requirement for duration is for it to be long enough so =20= that it isn't absorbed by any hysteresis mechanism that might be =20 sitting on top of it, and short enough so that the protocol isn't =20 held down for "too long" (another ugly interaction.) --Dave On Mar 30, 2007, at 10:21 AM, Naiming Shen wrote: > > hi bfd-wg, > > comments are welcome. > > thanks. > - Naiming From rtg-bfd-bounces@ietf.org Fri Mar 30 19:01:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXQ6B-0007Fw-4g; Fri, 30 Mar 2007 19:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXQ6A-0007Fp-3Y for rtg-bfd@ietf.org; Fri, 30 Mar 2007 19:01:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXQ68-0001qp-H8 for rtg-bfd@ietf.org; Fri, 30 Mar 2007 19:01:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2007 16:01:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2UN1V3w026206; Fri, 30 Mar 2007 16:01:31 -0700 Received: from [128.107.98.28] ([128.107.98.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2UN1VMF015427; Fri, 30 Mar 2007 23:01:32 GMT In-Reply-To: <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Naiming Shen Date: Fri, 30 Mar 2007 16:01:30 -0700 To: Dave Katz X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5506; t=1175295691; x=1176159691; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20; bh=FWyPjAvOijcziqUzTo6EXSJDGqlAsnBzODgpxa2PVCs=; b=rkJlnhL6BZ3LdvqWnCvmLbP3YbS5RMHXRMbAv9fCEnxIivmdqyj4fcGNFXNgKD6OM3doBX+e 0no9UAAejDdCL5yqwi08mvnrk9gvir7PPlxoGph/i1qALYB1J4WT8gbA; Authentication-Results: sj-dkim-2; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.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: , Errors-To: rtg-bfd-bounces@ietf.org Hi Dave, Good comments, see some replies inline. On Mar 30, 2007, at 2:44 PM, Dave Katz wrote: > Hi Naiming, thanks for submitting this. > > I've pointed out privately to Naiming that I think this is a rather =20= > ugly architectural hack, albeit a pragmatic one. The Right Way=99 to =20= > do this would be to run BFD directly over the datalink layer and =20 > take down all data protocols (but not the datalink) in sympathy =20 > with the BFD session state. However, there are (at least) two =20 > problems with this. Firstly, it means specifying how to run BFD =20 > over a plethora of datalink layers. Secondly, the IETF cannot =20 > standardize how to run BFD over datalink layers it does not control =20= > (so we could standardize something directly over PPP, for example, =20 > but not IEEE or cisco HDLC.) Yes, ugly architecture to avoid endless of clean work;-) only trying =20 to be an engineer. > > The architectural ugliness, aside from being a layer violation, =20 > rears its head in a couple of ways related to fate-sharing. =20 > Firstly, it means that everything shares fate with the IP over =20 > which BFD is being run, so if, say, IPv4 forwarding fails, non-v4 =20 > applications will see the failure. This isn't *too* terrible; it =20 > means that there may be false negatives, causing the application to =20= > temporarily flap. > > But secondly, there is a self-referential problem. What you'd =20 > *really* like to do on a BFD failure is to take down the failing =20 > protocol and keep it down until the BFD session resumes. But you =20 > can't do this if BFD is running on top of that failing protocol =20 > (which it will be) which thus requires the "special flag" hack and =20 > only temporarily taking down the protocol. The fate-sharing =20 > implications of this are more serious, because it is possible to =20 > get false positives in some cases when the data protocol has =20 > failed. Imagine, for example, running ISIS with this method. If =20 > IPv4 fails, the BFD session goes down, the interface flaps for five =20= > seconds, and then is reenabled. At that point ISIS will happily =20 > come back up and report IP reachability even though it doesn't =20 > exist. You can bet that folks who have not yet implemented BFD =20 > will be tempted to do this. I don't quick get this point. Let's take an easy example: if the bfd =20 always uses the connected nexthop of the peer address as it's bfd peer address, how =20 ISIS is doing should be independent of the intf-p2p BFD session and vise versa. If you are talking about sharing fate between ipv4 bfd and ISIS is a =20 problem, then I agree, this scheme is only meant for sharing fate among protocols, it should =20= not be used if this assumption is not true. But using ISIS to carry IP =20 information itself is violating this principle;-) don't know who to blame, although it's not a BFD issue. if you are talking about bfd connection depending on the ISIS routes, =20= then the original BFD spec also has this problem, this is not a new feature of this draft. > > My other objection to the "special flag" is that it is arguably =20 > overspecified. As far as I can tell, this is isomorphic with =20 > simply having static routes interact with BFD "directly" and is =20 > already covered by the generic spec (which carefully says only what =20= > the effect of the interaction should be, not the implementation of =20 > it.) It is an explicit signaling mechanism from BFD, albeit a =20 > primitive one. Ok, I agree. This 'special flag' is not a requirement of this scheme, =20= it's a purely implementation issue, be it a 'flag', a 'registration/callback' function, or =20 something else. I'll change that part. > > In light of this, my preference would be for all of the verbiage =20 > about static routes and dynamic protocols and special fiags to be =20 > removed. In place of this, add text that is very specific about =20 > the fate-sharing implications of this mechanism as outlined above, =20 > and point out that any application of BFD that does not =20 > automatically share fate with the data protocol over which BFD is =20 > running (such as ISIS or static routes) MUST have some form of =20 > explicit interaction with BFD in order to avoid false positives, =20 > and leave it at that. The "special bit" hack is orthogonal to this =20= > mechanism; it could just as well have been specified in the =20 > generic spec (and would have been just as inappropriate there.) I think the dynamic and static difference still needs to be =20 mentioned, although should not be directly linked with a 'special flag' for the static routing. > > It would be nice to point out that the only function of flapping =20 > the interface is to provide an Up->Down edge for protocols to see, =20 > and that the only requirement for duration is for it to be long =20 > enough so that it isn't absorbed by any hysteresis mechanism that =20 > might be sitting on top of it, and short enough so that the =20 > protocol isn't held down for "too long" (another ugly interaction.) > Yes, I should emphasize this Up->Down edge transition and the timing =20 thing as suggested in this draft. thanks again. - Naiming > --Dave > > On Mar 30, 2007, at 10:21 AM, Naiming Shen wrote: > >> >> hi bfd-wg, >> >> comments are welcome. >> >> thanks. >> - Naiming From rtg-bfd-bounces@ietf.org Fri Mar 30 19:41:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXQiP-0005ja-5C; Fri, 30 Mar 2007 19:41:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXQiO-0005iU-I2 for rtg-bfd@ietf.org; Fri, 30 Mar 2007 19:41:04 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXQiN-0004qh-Af for rtg-bfd@ietf.org; Fri, 30 Mar 2007 19:41:04 -0400 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by borg.juniper.net with ESMTP; 30 Mar 2007 16:41:03 -0700 X-IronPort-AV: i="4.14,355,1170662400"; d="scan'208"; a="699772392:sNHT34525576" Received: from electron.jnpr.net ([172.24.15.21]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 16:41:02 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2007 16:41:01 -0700 Message-ID: <5EB31780BD297F46812C8F495FA08F620B55FC95@electron.jnpr.net> In-Reply-To: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt Thread-Index: Acdy8Atfh055QwCIQ9OIJEZnf99/TgAM+hkQ From: "Nitin Bahadur" To: "Naiming Shen" , X-OriginalArrivalTime: 30 Mar 2007 23:41:02.0510 (UTC) FILETIME=[E0748CE0:01C77324] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: RE: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.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: , Errors-To: rtg-bfd-bounces@ietf.org Not sure of the exact problem you are trying to solve. Instead of using BFD as a link failure detection mechanism for Ethernet, can't you use Ethernet OAM? If this draft is a stop-gap mechanism before Ethernet OAM is implemented/put-in-use, maybe it's ok. To implement the draft correctly, a lot of special case handling would need to be added in multiple places. It would be better to use a link-layer mechanism for detecting link failures. Also, with the draft you are tying in the concept of a link failure to a bfd session failure...which might not necessarily be true. BFD sessions might fail due to firewall filters, IP packet handling errors. You would need more tools to tell the customer/operator that the link is *actually not down* and it's BFD that has marked the link as down. Nitin From rtg-bfd-bounces@ietf.org Fri Mar 30 19:55:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXQvU-0004nz-23; Fri, 30 Mar 2007 19:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXQvS-0004nu-N7 for rtg-bfd@ietf.org; Fri, 30 Mar 2007 19:54:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXQvR-0006Y2-Dt for rtg-bfd@ietf.org; Fri, 30 Mar 2007 19:54:34 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2007 16:54:34 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2UNsW8U028098; Fri, 30 Mar 2007 16:54:32 -0700 Received: from [128.107.130.83] (naiming-linux.cisco.com [128.107.130.83]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2UNsWA8019483; Fri, 30 Mar 2007 23:54:32 GMT Message-ID: <460DA338.4020505@cisco.com> Date: Fri, 30 Mar 2007 16:54:32 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nitin Bahadur References: <5EB31780BD297F46812C8F495FA08F620B55FC95@electron.jnpr.net> In-Reply-To: <5EB31780BD297F46812C8F495FA08F620B55FC95@electron.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1426; t=1175298872; x=1176162872; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt |Sender:=20; bh=Y3n+1AtzldHG1a+HTVnwyWa6X0QC2FerdW3pYfiZGeI=; b=SGaiJAYQTUJUJ0Bqm11mEXiiwcNS/M7pHDeSk9WwupcDTAAgwcjMJAFoeVAcOZNKNQW4kyyM zih6HU5lwwxQDlr3RkjDaFFOUxaitrZ0Dk4Z/2YlXzOT19facOpB0DfT; Authentication-Results: sj-dkim-5; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.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: , Errors-To: rtg-bfd-bounces@ietf.org Nitin Bahadur said the following on 03/30/2007 04:41 PM: > Not sure of the exact problem you are trying to solve. Instead of using > BFD as a link failure detection mechanism for Ethernet, can't you use > Ethernet OAM? If this draft is a stop-gap mechanism before Ethernet OAM > is implemented/put-in-use, maybe it's ok. If Ethernet OAM works for you, yes use it. This draft is not just designed for Ethernet though. > > To implement the draft correctly, a lot of special case handling would > need to be added in multiple places. It would be better to use a > link-layer mechanism for detecting link failures. You mean bring down and bring up and intf is more work than putting hooks everywhere in every protocol and every service? not to speak for every implementations, for certain ones, one and half day of coding and testing should cover this draft. > > Also, with the draft you are tying in the concept of a link failure to a > bfd session failure...which might not necessarily be true. BFD sessions > might fail due to firewall filters, IP packet handling errors. You would > need more tools to tell the customer/operator that the link is *actually > not down* and it's BFD that has marked the link as down. to be honest, generate an meaningful error message saying 'intf-p2p bfd brought down intf' will probably do for most of the customers. thanks. - Naiming > > Nitin From rtg-bfd-bounces@ietf.org Fri Mar 30 20:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXRq4-0005Fz-P2; Fri, 30 Mar 2007 20:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXRq3-0005Fp-Gs for rtg-bfd@ietf.org; Fri, 30 Mar 2007 20:53:03 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXRq1-000585-NR for rtg-bfd@ietf.org; Fri, 30 Mar 2007 20:53:03 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 30 Mar 2007 17:53:02 -0700 X-IronPort-AV: i="4.14,355,1170662400"; d="scan'208"; a="699791604:sNHT36801428" 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 l2V0qvJ61946; Fri, 30 Mar 2007 17:53:01 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <448453AC-AAC4-4924-8BF2-87AC85907252@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Fri, 30 Mar 2007 17:52:56 -0700 To: Naiming Shen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.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: , Errors-To: rtg-bfd-bounces@ietf.org On Mar 30, 2007, at 4:01 PM, Naiming Shen wrote: >> >> But secondly, there is a self-referential problem. What you'd >> *really* like to do on a BFD failure is to take down the failing >> protocol and keep it down until the BFD session resumes. But you >> can't do this if BFD is running on top of that failing protocol >> (which it will be) which thus requires the "special flag" hack and >> only temporarily taking down the protocol. The fate-sharing >> implications of this are more serious, because it is possible to >> get false positives in some cases when the data protocol has >> failed. Imagine, for example, running ISIS with this method. If >> IPv4 fails, the BFD session goes down, the interface flaps for >> five seconds, and then is reenabled. At that point ISIS will >> happily come back up and report IP reachability even though it >> doesn't exist. You can bet that folks who have not yet >> implemented BFD will be tempted to do this. > > > If you are talking about sharing fate between ipv4 bfd and ISIS is > a problem, then I agree, > this scheme is only meant for sharing fate among protocols, it > should not be used > if this assumption is not true. But using ISIS to carry IP > information itself is violating this > principle;-) don't know who to blame, although it's not a BFD issue. I guess my point is that you need to be very explicit about what works and what doesn't. It's certainly the case that, without the presence of BFD, ISIS will do Bad Things if IP forwarding breaks, since it will continue to advertise IP connectivity. But the whole point of BFD is to sense data protocol connectivity and provide that (presumably useful) information to other parts of a system. If BFD is providing information directly to ISIS, it can withdraw IP connectivity (or tear down the adjacency if need be) and keep it that way until connectivity is restored. If ISIS relied on this scheme, and IP connectivity failed (but datalink connectivity remained), the ISIS adjacency would flap, and then ISIS would proceed to black hole traffic. I think you need to specifically disallow this mechanism for cases like this, namely, applications that will continue to run even with the failure of a data protocol, but whose correct operation requires that data protocol. (Note that this sentence describes both ISIS and static routes.) OSPFv3 is another interesting example if you're running BFD in this configuration only over IPv4. If there is a v4 failure, OSPFv3 will flap unnecessarily. This gets back to the IPv4 == everything fate sharing that is at the heart of the way you've specified it, and which I think is an unnecessary restriction. A number of systems (including the one I'm most familiar with these days) has an interface hierarchy that includes the data protocol. Such systems are likely better served by having, say, separate v4 and v6 BFD sessions and flapping the appropriate data protocol up/down status in the face of a BFD session failure. This would allow the OSPFv3 case to run unmolested when v4 died. I would suggest to at least offer this up as a MAY when you discuss the fate sharing implications of this mechanism, since it should be essentially no more work to implement if the system is already built this way. >> >> In light of this, my preference would be for all of the verbiage >> about static routes and dynamic protocols and special fiags to be >> removed. In place of this, add text that is very specific about >> the fate-sharing implications of this mechanism as outlined above, >> and point out that any application of BFD that does not >> automatically share fate with the data protocol over which BFD is >> running (such as ISIS or static routes) MUST have some form of >> explicit interaction with BFD in order to avoid false positives, >> and leave it at that. The "special bit" hack is orthogonal to >> this mechanism; it could just as well have been specified in the >> generic spec (and would have been just as inappropriate there.) > > I think the dynamic and static difference still needs to be > mentioned, although should not > be directly linked with a 'special flag' for the static routing. But I think the "difference" here is fundamental--as soon as you have any special case communication between BFD and a part of the system, you've basically discarded the point of the draft (if I understand it) which is to be able to leverage BFD without changing your "clients" to specifically use it. What you're specifying here is functionally *exactly* the same as what the generic spec talks about for static routes and other non-protocol applications, and only muddies the spec, IMHO. Why not just say that this mechanism only provides a way of more rapidly taking down applications that would otherwise go down eventually and which will stay down on their own until the path is healed (namely, control protocols), and leave statics out of it altogether? --Dave From rtg-bfd-bounces@ietf.org Fri Mar 30 21:30:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXSPs-0001Of-C6; Fri, 30 Mar 2007 21:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXSPq-0001Oa-WB for rtg-bfd@ietf.org; Fri, 30 Mar 2007 21:30:03 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXSPp-00035r-EJ for rtg-bfd@ietf.org; Fri, 30 Mar 2007 21:30:02 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2007 18:30:01 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2V1U05d024782; Fri, 30 Mar 2007 18:30:00 -0700 Received: from [128.107.98.28] ([128.107.98.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2V1TwZT023009; Sat, 31 Mar 2007 01:30:00 GMT In-Reply-To: <448453AC-AAC4-4924-8BF2-87AC85907252@juniper.net> References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> <448453AC-AAC4-4924-8BF2-87AC85907252@juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Naiming Shen Date: Fri, 30 Mar 2007 18:29:56 -0700 To: Dave Katz X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6906; t=1175304600; x=1176168600; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20; bh=XyvgCLnGlba+QgAO8rSh4Cev3f0FNXXcZlKkrsyg89E=; b=XxBoJumuKL3zumm1jMrPZxD5nOiKT4icBy6kOm1b62UtFFeFse4pMtaQA2bf5SpHS+swAqia vf6fYI3DjLpWBezSn84aFFZkPY9aqC/prwTm5ihbGWwY2YzlfllHdCm9; Authentication-Results: sj-dkim-3; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.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: , Errors-To: rtg-bfd-bounces@ietf.org On Mar 30, 2007, at 5:52 PM, Dave Katz wrote: > > On Mar 30, 2007, at 4:01 PM, Naiming Shen wrote: > >>> >>> But secondly, there is a self-referential problem. What you'd >>> *really* like to do on a BFD failure is to take down the failing >>> protocol and keep it down until the BFD session resumes. But you >>> can't do this if BFD is running on top of that failing protocol >>> (which it will be) which thus requires the "special flag" hack >>> and only temporarily taking down the protocol. The fate-sharing >>> implications of this are more serious, because it is possible to >>> get false positives in some cases when the data protocol has >>> failed. Imagine, for example, running ISIS with this method. If >>> IPv4 fails, the BFD session goes down, the interface flaps for >>> five seconds, and then is reenabled. At that point ISIS will >>> happily come back up and report IP reachability even though it >>> doesn't exist. You can bet that folks who have not yet >>> implemented BFD will be tempted to do this. >> >> >> If you are talking about sharing fate between ipv4 bfd and ISIS is >> a problem, then I agree, >> this scheme is only meant for sharing fate among protocols, it >> should not be used >> if this assumption is not true. But using ISIS to carry IP >> information itself is violating this >> principle;-) don't know who to blame, although it's not a BFD issue. > > I guess my point is that you need to be very explicit about what > works and what doesn't. It's certainly the case that, without the > presence of BFD, ISIS will do Bad Things if IP forwarding breaks, > since it will continue to advertise IP connectivity. But the whole > point of BFD is to sense data protocol connectivity and provide > that (presumably useful) information to other parts of a system. > If BFD is providing information directly to ISIS, it can withdraw > IP connectivity (or tear down the adjacency if need be) and keep it > that way until connectivity is restored. If ISIS relied on this > scheme, and IP connectivity failed (but datalink connectivity > remained), the ISIS adjacency would flap, and then ISIS would > proceed to black hole traffic. Even in the normal BFD interacting with ISIS(for ipv4), I would think it can also do this black holing. Since ipv4 bfd session is flapping, and datalink layer is fine, and ISIS packets is going through ok, hellos are happy. ISIS will bring up the adjacency, and then register with bfd, and bfd later failed again, which will bring down the ISIS session. I fail to see the difference between the two schemes. > > I think you need to specifically disallow this mechanism for cases > like this, namely, applications that will continue to run even with > the failure of a data protocol, but whose correct operation > requires that data protocol. (Note that this sentence describes > both ISIS and static routes.) > > OSPFv3 is another interesting example if you're running BFD in this > configuration only over IPv4. If there is a v4 failure, OSPFv3 > will flap unnecessarily. This gets back to the IPv4 == everything > fate sharing that is at the heart of the way you've specified it, > and which I think is an unnecessary restriction. A number of > systems (including the one I'm most familiar with these days) has > an interface hierarchy that includes the data protocol. Such > systems are likely better served by having, say, separate v4 and v6 > BFD sessions and flapping the appropriate data protocol up/down > status in the face of a BFD session failure. This would allow the > OSPFv3 case to run unmolested when v4 died. I would suggest to at > least offer this up as a MAY when you discuss the fate sharing > implications of this mechanism, since it should be essentially no > more work to implement if the system is already built this way. Sure. There can be an configuration option for bring down the whole thing or bring down the data protocol part if the platform supports that. Even though from architecture wise, the separation of bfds is clean, ipv4 controls the ipv4 protocols and ipv6 controls the ipv6 protocols. there are still much to be desired from implementation point of angle. On many routers BFD packets going out not really through the exact data packets forwarding path or the packets are sent out from the same software process, be it v6 or v6. So the argument of data separation is rather mood. And I'm yet to see a case BFD session down is actually caused by the layer 3 lookup engine which is only responsible for ipv4;-) I would rather do the re-route altogether though if we know one of the data plane is already in trouble. > >>> >>> In light of this, my preference would be for all of the verbiage >>> about static routes and dynamic protocols and special fiags to be >>> removed. In place of this, add text that is very specific about >>> the fate-sharing implications of this mechanism as outlined >>> above, and point out that any application of BFD that does not >>> automatically share fate with the data protocol over which BFD is >>> running (such as ISIS or static routes) MUST have some form of >>> explicit interaction with BFD in order to avoid false positives, >>> and leave it at that. The "special bit" hack is orthogonal to >>> this mechanism; it could just as well have been specified in the >>> generic spec (and would have been just as inappropriate there.) >> >> I think the dynamic and static difference still needs to be >> mentioned, although should not >> be directly linked with a 'special flag' for the static routing. > > But I think the "difference" here is fundamental--as soon as you > have any special case communication between BFD and a part of the > system, you've basically discarded the point of the draft (if I > understand it) which is to be able to leverage BFD without changing > your "clients" to specifically use it. What you're specifying here > is functionally *exactly* the same as what the generic spec talks > about for static routes and other non-protocol applications, and > only muddies the spec, IMHO. only the UP->Down portion is different between the two schemes. the rest is the same. but the bring down itself is different from the point of dynamic or static. > > Why not just say that this mechanism only provides a way of more > rapidly taking down applications that would otherwise go down > eventually and which will stay down on their own until the path is > healed (namely, control protocols), and leave statics out of it > altogether? Maybe you have a point. I'll think about that. thanks. - Naiming > > > --Dave From rtg-bfd-bounces@ietf.org Fri Mar 30 22:21:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXTCh-0005MR-1D; Fri, 30 Mar 2007 22:20:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXTCf-0005MJ-UN for rtg-bfd@ietf.org; Fri, 30 Mar 2007 22:20:29 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXTCe-0005z6-FX for rtg-bfd@ietf.org; Fri, 30 Mar 2007 22:20:29 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 30 Mar 2007 19:20:28 -0700 X-IronPort-AV: i="4.14,355,1170662400"; d="scan'208"; a="699811243:sNHT37467600" 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 l2V2KRJ74582; Fri, 30 Mar 2007 19:20:27 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> <448453AC-AAC4-4924-8BF2-87AC85907252@juniper.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4875A54C-08E4-4EE2-91C4-3F4E132AE7A4@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Fri, 30 Mar 2007 19:20:26 -0700 To: Naiming Shen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.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: , Errors-To: rtg-bfd-bounces@ietf.org On Mar 30, 2007, at 6:29 PM, Naiming Shen wrote: >> >> I guess my point is that you need to be very explicit about what >> works and what doesn't. It's certainly the case that, without the >> presence of BFD, ISIS will do Bad Things if IP forwarding breaks, >> since it will continue to advertise IP connectivity. But the >> whole point of BFD is to sense data protocol connectivity and >> provide that (presumably useful) information to other parts of a >> system. If BFD is providing information directly to ISIS, it can >> withdraw IP connectivity (or tear down the adjacency if need be) >> and keep it that way until connectivity is restored. If ISIS >> relied on this scheme, and IP connectivity failed (but datalink >> connectivity remained), the ISIS adjacency would flap, and then >> ISIS would proceed to black hole traffic. > > Even in the normal BFD interacting with ISIS(for ipv4), I would > think it can also do this > black holing. Since ipv4 bfd session is flapping, and datalink > layer is fine, and ISIS > packets is going through ok, hellos are happy. ISIS will bring up > the adjacency, and > then register with bfd, and bfd later failed again, which will > bring down the ISIS session. > I fail to see the difference between the two schemes. In the v4 failure case, the BFD session would stay down, and the ISIS adjacencies (or announcement of IP reachability) would be held down as well, thus no black hole. The problem in this scheme is that the circularity problem requires that you only temporarily assert that the interface is down; you can't hold the whole interface down because BFD would never be able to come up. Thus in this case ISIS would not know that IP reachability was still broken, and would black hole the traffic. > >> >> I think you need to specifically disallow this mechanism for cases >> like this, namely, applications that will continue to run even >> with the failure of a data protocol, but whose correct operation >> requires that data protocol. (Note that this sentence describes >> both ISIS and static routes.) >> >> OSPFv3 is another interesting example if you're running BFD in >> this configuration only over IPv4. If there is a v4 failure, >> OSPFv3 will flap unnecessarily. This gets back to the IPv4 == >> everything fate sharing that is at the heart of the way you've >> specified it, and which I think is an unnecessary restriction. A >> number of systems (including the one I'm most familiar with these >> days) has an interface hierarchy that includes the data protocol. >> Such systems are likely better served by having, say, separate v4 >> and v6 BFD sessions and flapping the appropriate data protocol up/ >> down status in the face of a BFD session failure. This would >> allow the OSPFv3 case to run unmolested when v4 died. I would >> suggest to at least offer this up as a MAY when you discuss the >> fate sharing implications of this mechanism, since it should be >> essentially no more work to implement if the system is already >> built this way. > > Sure. There can be an configuration option for bring down the whole > thing or bring > down the data protocol part if the platform supports that. > > Even though from architecture wise, the separation of bfds is > clean, ipv4 controls the > ipv4 protocols and ipv6 controls the ipv6 protocols. there are > still much to be desired > from implementation point of angle. On many routers BFD packets > going out not really > through the exact data packets forwarding path or the packets are > sent out from the > same software process, be it v6 or v6. So the argument of data > separation is rather > mood. And I'm yet to see a case BFD session down is actually caused > by the layer 3 > lookup engine which is only responsible for ipv4;-) I would rather > do the re-route > altogether though if we know one of the data plane is already in > trouble. But once again, because of the temporary nature of the "downness" of the interface, it will not really reroute the second protocol, but just cause it to flap (twice.) But so long as the spec allows multiple sessions (since currently it does not) we can leave the mootness or lack thereof to the individual implementor. > >> >> But I think the "difference" here is fundamental--as soon as you >> have any special case communication between BFD and a part of the >> system, you've basically discarded the point of the draft (if I >> understand it) which is to be able to leverage BFD without >> changing your "clients" to specifically use it. What you're >> specifying here is functionally *exactly* the same as what the >> generic spec talks about for static routes and other non-protocol >> applications, and only muddies the spec, IMHO. > > only the UP->Down portion is different between the two schemes. the > rest is the same. > but the bring down itself is different from the point of dynamic or > static. But the "bring down" is the crux of the proposal. > >> >> Why not just say that this mechanism only provides a way of more >> rapidly taking down applications that would otherwise go down >> eventually and which will stay down on their own until the path is >> healed (namely, control protocols), and leave statics out of it >> altogether? > > Maybe you have a point. I'll think about that. Thanks... --Dave From rtg-bfd-bounces@ietf.org Fri Mar 30 23:00:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXTpI-0004vf-AU; Fri, 30 Mar 2007 23:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXTpH-0004va-AZ for rtg-bfd@ietf.org; Fri, 30 Mar 2007 23:00:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXTpF-000468-O2 for rtg-bfd@ietf.org; Fri, 30 Mar 2007 23:00:23 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2007 20:00:22 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l2V30Ltj008847; Fri, 30 Mar 2007 20:00:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2V30LA8028891; Sat, 31 Mar 2007 03:00:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 20:00:21 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 20:00:20 -0700 In-Reply-To: <4875A54C-08E4-4EE2-91C4-3F4E132AE7A4@juniper.net> References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> <448453AC-AAC4-4924-8BF2-87AC85907252@juniper.net> <4875A54C-08E4-4EE2-91C4-3F4E132AE7A4@juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B7EF97C-29FF-4942-B8DF-598D3759C444@cisco.com> Content-Transfer-Encoding: 7bit From: Naiming Shen Date: Fri, 30 Mar 2007 20:00:19 -0700 To: Dave Katz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Mar 2007 03:00:20.0708 (UTC) FILETIME=[B818C240:01C77340] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6507; t=1175310021; x=1176174021; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20; bh=mkMsWROs1QbKo1X1HLK5arhB6C04t7AFA8KlXAS3kqw=; b=LjlYPlEnjEgZ0dmubFqHLTIJ6W4CmXfS+hCeLtm8Tm72rNjnnezqH+k2wMyMoHhSvBh6b5pf 42qULpDrRQfdrrOmgdH1IQQoO0G2o/7dE3m6Iypecww+BqCbTCb716Sm; Authentication-Results: sj-dkim-7; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.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: , Errors-To: rtg-bfd-bounces@ietf.org On Mar 30, 2007, at 7:20 PM, Dave Katz wrote: > > On Mar 30, 2007, at 6:29 PM, Naiming Shen wrote: > >>> >>> I guess my point is that you need to be very explicit about what >>> works and what doesn't. It's certainly the case that, without >>> the presence of BFD, ISIS will do Bad Things if IP forwarding >>> breaks, since it will continue to advertise IP connectivity. But >>> the whole point of BFD is to sense data protocol connectivity and >>> provide that (presumably useful) information to other parts of a >>> system. If BFD is providing information directly to ISIS, it can >>> withdraw IP connectivity (or tear down the adjacency if need be) >>> and keep it that way until connectivity is restored. If ISIS >>> relied on this scheme, and IP connectivity failed (but datalink >>> connectivity remained), the ISIS adjacency would flap, and then >>> ISIS would proceed to black hole traffic. >> >> Even in the normal BFD interacting with ISIS(for ipv4), I would >> think it can also do this >> black holing. Since ipv4 bfd session is flapping, and datalink >> layer is fine, and ISIS >> packets is going through ok, hellos are happy. ISIS will bring up >> the adjacency, and >> then register with bfd, and bfd later failed again, which will >> bring down the ISIS session. >> I fail to see the difference between the two schemes. > > In the v4 failure case, the BFD session would stay down, and the > ISIS adjacencies (or announcement of IP reachability) would be held > down as well, thus no black hole. The problem in this scheme is > that the circularity problem requires that you only temporarily > assert that the interface is down; you can't hold the whole > interface down because BFD would never be able to come up. Thus in > this case ISIS would not know that IP reachability was still > broken, and would black hole the traffic. Ok, I see your point. So in this case as you mentioned, isis dealing could be categorized or implemented the same as static routing if this is a concern. > >> >>> >>> I think you need to specifically disallow this mechanism for >>> cases like this, namely, applications that will continue to run >>> even with the failure of a data protocol, but whose correct >>> operation requires that data protocol. (Note that this sentence >>> describes both ISIS and static routes.) >>> >>> OSPFv3 is another interesting example if you're running BFD in >>> this configuration only over IPv4. If there is a v4 failure, >>> OSPFv3 will flap unnecessarily. This gets back to the IPv4 == >>> everything fate sharing that is at the heart of the way you've >>> specified it, and which I think is an unnecessary restriction. A >>> number of systems (including the one I'm most familiar with these >>> days) has an interface hierarchy that includes the data >>> protocol. Such systems are likely better served by having, say, >>> separate v4 and v6 BFD sessions and flapping the appropriate data >>> protocol up/down status in the face of a BFD session failure. >>> This would allow the OSPFv3 case to run unmolested when v4 died. >>> I would suggest to at least offer this up as a MAY when you >>> discuss the fate sharing implications of this mechanism, since it >>> should be essentially no more work to implement if the system is >>> already built this way. >> >> Sure. There can be an configuration option for bring down the >> whole thing or bring >> down the data protocol part if the platform supports that. >> >> Even though from architecture wise, the separation of bfds is >> clean, ipv4 controls the >> ipv4 protocols and ipv6 controls the ipv6 protocols. there are >> still much to be desired >> from implementation point of angle. On many routers BFD packets >> going out not really >> through the exact data packets forwarding path or the packets are >> sent out from the >> same software process, be it v6 or v6. So the argument of data >> separation is rather >> mood. And I'm yet to see a case BFD session down is actually >> caused by the layer 3 >> lookup engine which is only responsible for ipv4;-) I would rather >> do the re-route >> altogether though if we know one of the data plane is already in >> trouble. > > But once again, because of the temporary nature of the "downness" > of the interface, it will not really reroute the second protocol, > but just cause it to flap (twice.) But so long as the spec allows > multiple sessions (since currently it does not) we can leave the > mootness or lack thereof to the individual implementor. Ok. > >> >>> >>> But I think the "difference" here is fundamental--as soon as you >>> have any special case communication between BFD and a part of the >>> system, you've basically discarded the point of the draft (if I >>> understand it) which is to be able to leverage BFD without >>> changing your "clients" to specifically use it. What you're >>> specifying here is functionally *exactly* the same as what the >>> generic spec talks about for static routes and other non-protocol >>> applications, and only muddies the spec, IMHO. >> >> only the UP->Down portion is different between the two schemes. >> the rest is the same. >> but the bring down itself is different from the point of dynamic >> or static. > > But the "bring down" is the crux of the proposal. > Something else reminds that, there is a difference between the normal bring up stage and this scheme in terms of the 'non-dynamic' applications, that was why I wrote this 'special flag' in the first place, is that the flag/callback/whatever with this scheme can be an interface based trick, which is very easy to implement (or some multiple interface/dataplane based) ; while the normal bfd which is nexthop based, need to have proper registration/etc mechanism, it's rather hard to handle. It may worth to mention this in the draft. thanks. - Naiming >> >>> >>> Why not just say that this mechanism only provides a way of more >>> rapidly taking down applications that would otherwise go down >>> eventually and which will stay down on their own until the path >>> is healed (namely, control protocols), and leave statics out of >>> it altogether? >> >> Maybe you have a point. I'll think about that. > > Thanks... > > --Dave