From root@core3.amsl.com Tue Jan 5 20:30:02 2010 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6AFC63A6873; Tue, 5 Jan 2010 20:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-multihop-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100106043002.6AFC63A6873@core3.amsl.com> Date: Tue, 5 Jan 2010 20:30:02 -0800 (PST) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 04:30:02 -0000 --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-09.txt Pages : 7 Date : 2010-01-05 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-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-bfd-multihop-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-05201838.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Jan 5 20:30:02 2010 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8B8453A687E; Tue, 5 Jan 2010 20:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-v4v6-1hop-11.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100106043002.8B8453A687E@core3.amsl.com> Date: Tue, 5 Jan 2010 20:30:02 -0800 (PST) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 04:30:02 -0000 --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-11.txt Pages : 8 Date : 2010-01-05 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-05201900.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Jan 5 21:15:02 2010 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1D61A3A677D; Tue, 5 Jan 2010 21:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-base-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100106051502.1D61A3A677D@core3.amsl.com> Date: Tue, 5 Jan 2010 21:15:01 -0800 (PST) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 05:15:02 -0000 --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-10.txt Pages : 51 Date : 2010-01-05 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. 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-bfd-base-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-05210306.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Jan 14 21:15:02 2010 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 139193A67EA; Thu, 14 Jan 2010 21:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-base-11.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100115051502.139193A67EA@core3.amsl.com> Date: Thu, 14 Jan 2010 21:15:02 -0800 (PST) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 05:15:02 -0000 --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-11.txt Pages : 51 Date : 2010-01-14 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. 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-bfd-base-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-14210755.I-D@ietf.org> --NextPart-- From BARTW@nortel.com Thu Jan 21 09:51:22 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3DB3A6924 for ; Thu, 21 Jan 2010 09:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h79utNwHVIvz for ; Thu, 21 Jan 2010 09:51:21 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 26F503A6A61 for ; Thu, 21 Jan 2010 09:51:20 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o0LHpBc28054 for ; Thu, 21 Jan 2010 17:51:11 GMT 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 Subject: BFD Hold Down Timers Date: Thu, 21 Jan 2010 12:51:02 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41ACB0417@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD Hold Down Timers Thread-Index: AcqawkwWaJ+l24osRXSvsaPPn3XbjQ== From: "Bart Wensley" To: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:51:22 -0000 Hi, We have been asked to support a hold down timer in our BFD implementation. The purpose of the timer would be to delay state change notifications (for a BFD session going from down to up) for the duration of the timer (which could be on the order of minutes). This would delay the re-establishment of a routing adjacency (e.g. BGP, OSPF) until the hold down timer has expired. From a search on the web, I see that Juniper has implemented this in JUNOS 8.5 and I believe this is one reason=20 we are being asked to support it. This would be pretty straight forward, except we have also been told that the hold down timer should have the following side effects on BFD:=20 1. If the hold time timer is configured and a BFD session goes into the admin down state, any clients (e.g. BGP, OSPF) should treat this as the down state and break their adjacencies. This is in direct conflict with draft-ietf-bfd-generic-05, section 4.1: If the session state on either the local or remote system=20 (if known) is AdminDown, BFD has been administratively=20 disabled, and the establishment of a control protocol=20 adjacency MUST be allowed. 2. If the hold down timer is configured, prevent the establishment of the routing adjacency until the BFD session comes up. The implication is that if the hold down timer is=20 not configured, the routing adjacency should be allowed before the BFD session comes up. From looking through discussions=20 this mailing list, it seems there is some confusion as to=20 which is the correct behaviour, although I don't think using=20 hold down timer configuration is the right way to resolve it. This is third hand information, so I apologize if it is incorrect. I have searched the BFD drafts and this mailing list and I have not found any discussion of a hold down timer having these side effects. Can someone from Juniper confirm whether JUNOS behaves this way when hold down timers are used? If so:=20 - Is this behaviour documented anywhere? - Will this be added to one of the BFD drafts? I'm also curious about whether any other vendors have implemented hold down timers with (or without) these side effects. If vendors are modifying their BFD implementations like this, I can see it making inter-vendor interop difficult if the behaviour is not standardized. Thanks, Bart Wensley Versatile Services Engine Software Design Nortel bartw@nortel.com From dkatz@juniper.net Thu Jan 21 10:31:56 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6EA3A69F7 for ; Thu, 21 Jan 2010 10:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE0QQO4TAVm6 for ; Thu, 21 Jan 2010 10:31:55 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 4830B28C173 for ; Thu, 21 Jan 2010 10:31:42 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS1idiSuuCp3X+dBuKL/jGM4WpNTfjXNk@postini.com; Thu, 21 Jan 2010 10:31:51 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Thu, 21 Jan 2010 10:25:29 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 10:25:29 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 10:25:29 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 10:25:28 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o0LIPRM30229; Thu, 21 Jan 2010 10:25:27 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <8E1FC330-B537-41DC-8A6C-3C9171402A3F@juniper.net> From: Dave Katz To: Bart Wensley In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41ACB0417@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: BFD Hold Down Timers Date: Thu, 21 Jan 2010 11:25:26 -0700 References: <713043CE8B8E1348AF3C546DBE02C1B41ACB0417@zcarhxm2.corp.nortel.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 Jan 2010 18:25:28.0408 (UTC) FILETIME=[1B80DD80:01CA9AC7] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 18:31:56 -0000 On Jan 21, 2010, at 10:51 AM, Bart Wensley wrote: > Hi, > > We have been asked to support a hold down timer in our BFD > implementation. The purpose of the timer would be to delay state > change notifications (for a BFD session going from down to up) > for the duration of the timer (which could be on the order of > minutes). This would delay the re-establishment of a routing > adjacency (e.g. BGP, OSPF) until the hold down timer has > expired. From a search on the web, I see that Juniper has > implemented this in JUNOS 8.5 and I believe this is one reason > we are being asked to support it. > > This would be pretty straight forward, except we have also been > told that the hold down timer should have the following side > effects on BFD: > > 1. If the hold time timer is configured and a BFD session goes > into the admin down state, any clients (e.g. BGP, OSPF) should > treat this as the down state and break their adjacencies. This > is in direct conflict with draft-ietf-bfd-generic-05, section > 4.1: > If the session state on either the local or remote system > (if known) is AdminDown, BFD has been administratively > disabled, and the establishment of a control protocol > adjacency MUST be allowed. The history of AdminDown state and its implications was somewhat fluid through the refinement of BFD, but the semantics we finally settled on were "We're not running BFD rignt now; please act as if nothing is wrong." The behavior you're looking for can be accommodated by holding down in Down state rather than AdminDown--see the base spec, section 6.8.18. If you're in Down rather than AdminDown state, you can stay there as long as you like, and the session will stay down but the session will still be trading packets, and so the state will hang around (and the protocols will stay down.) > > 2. If the hold down timer is configured, prevent the > establishment of the routing adjacency until the BFD session > comes up. The implication is that if the hold down timer is > not configured, the routing adjacency should be allowed before > the BFD session comes up. From looking through discussions > this mailing list, it seems there is some confusion as to > which is the correct behaviour, although I don't think using > hold down timer configuration is the right way to resolve it. The concept of a hold down timer is outside of the spec, so without a clear definition of what that means (in particular, what state you're holding down in) you can't talk about what the expected behavior would be. However, if you're holding down in Down state, the behavior seems clear (at least to me): Therefore, the establishment of control protocol adjacencies SHOULD be blocked if both systems are willing to establish a BFD session but a BFD session cannot be established. Exchanging BFD packets constitutes "both systems are willing to establish a BFD session", and one side not budging from Down state constitutes "cannot be established". > > This is third hand information, so I apologize if it is > incorrect. I have searched the BFD drafts and this mailing list > and I have not found any discussion of a hold down timer having > these side effects. > > Can someone from Juniper confirm whether JUNOS behaves this way > when hold down timers are used? If so: > - Is this behaviour documented anywhere? > - Will this be added to one of the BFD drafts? It would be inappropriate to talk about our particular implementation on this list (particularly if it has been overtaken by the specs ;-) ) but there should be no interoperability issues. > > I'm also curious about whether any other vendors have implemented > hold down timers with (or without) these side effects. If vendors > are modifying their BFD implementations like this, I can see it > making inter-vendor interop difficult if the behaviour is not > standardized. I don't believe that there are any interoperability issues if the specs are followed. --Dave From nitinb@juniper.net Thu Jan 21 10:39:48 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04AA28C197 for ; Thu, 21 Jan 2010 10:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS-zBc89ZVjl for ; Thu, 21 Jan 2010 10:39:47 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id E7ACF28C163 for ; Thu, 21 Jan 2010 10:39:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKS1ifS8CGxvh/8bsQQrINVrack8EqoO7k@postini.com; Thu, 21 Jan 2010 10:39:43 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 21 Jan 2010 10:37:52 -0800 From: Nitin Bahadur To: Bart Wensley , "rtg-bfd@ietf.org" Date: Thu, 21 Jan 2010 10:37:30 -0800 Subject: Re: BFD Hold Down Timers Thread-Topic: BFD Hold Down Timers Thread-Index: AcqawkwWaJ+l24osRXSvsaPPn3XbjQABn2Fm Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41ACB0417@zcarhxm2.corp.nortel.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 18:39:48 -0000 Hi Bart, See NB> below... On 1/21/10 9:51 AM, "Bart Wensley" wrote: Hi, We have been asked to support a hold down timer in our BFD implementation. The purpose of the timer would be to delay state change notifications (for a BFD session going from down to up) for the duration of the timer (which could be on the order of minutes). This would delay the re-establishment of a routing adjacency (e.g. BGP, OSPF) until the hold down timer has expired. From a search on the web, I see that Juniper has implemented this in JUNOS 8.5 and I believe this is one reason we are being asked to support it. This would be pretty straight forward, except we have also been told that the hold down timer should have the following side effects on BFD: 1. If the hold time timer is configured and a BFD session goes into the admin down state, any clients (e.g. BGP, OSPF) should treat this as the down state and break their adjacencies. NB> I am not sure what is the relation between the hold-down timer and "bfd= going down". As per your description above, the hold-down is related to bfd coming up an= d informing clients. This is in direct conflict with draft-ietf-bfd-generic-05, section 4.1: If the session state on either the local or remote system (if known) is AdminDown, BFD has been administratively disabled, and the establishment of a control protocol adjacency MUST be allowed. 2. If the hold down timer is configured, prevent the establishment of the routing adjacency until the BFD session comes up. The implication is that if the hold down timer is not configured, the routing adjacency should be allowed before the BFD session comes up. From looking through discussions this mailing list, it seems there is some confusion as to which is the correct behaviour, although I don't think using hold down timer configuration is the right way to resolve it. NB> There was some config for isis (see draft-ietf-isis-bfd-tlv). Besides t= hat...I don't remember any definite conclusion on what is the right way. This is third hand information, so I apologize if it is incorrect. I have searched the BFD drafts and this mailing list and I have not found any discussion of a hold down timer having these side effects. Can someone from Juniper confirm whether JUNOS behaves this way when hold down timers are used? If so: * Is this behaviour documented anywhere? NB> I will refrain from commenting on vendor specific behavior on a pu= blic forum. There is some documentation available publicly on JNPR website. - Will this be added to one of the BFD drafts? NB> Not that I am aware of. Thanks Nitin From BARTW@nortel.com Thu Jan 21 11:32:17 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BFA13A67EE for ; Thu, 21 Jan 2010 11:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE7eK5d6k1+j for ; Thu, 21 Jan 2010 11:32:16 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 32F653A6774 for ; Thu, 21 Jan 2010 11:32:16 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0LJW6e09781; Thu, 21 Jan 2010 19:32:06 GMT 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 Subject: RE: BFD Hold Down Timers Date: Thu, 21 Jan 2010 14:31:10 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41ACB0419@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD Hold Down Timers Thread-Index: AcqawkwWaJ+l24osRXSvsaPPn3XbjQABn2FmAAGhGTA= References: <713043CE8B8E1348AF3C546DBE02C1B41ACB0417@zcarhxm2.corp.nortel.com> From: "Bart Wensley" To: "Nitin Bahadur" Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 19:32:17 -0000 Nitin, I was summarizing what we had been asked to do: > 1. If the hold time timer is configured and a BFD session goes > into the admin down state, any clients (e.g. BGP, OSPF) should > treat this as the down state and break their adjacencies. You said: > NB> I am not sure what is the relation between the hold-down timer=20 > and "bfd going down". > As per your description above, the hold-down is related to bfd=20 > coming up and informing clients. There is no relation between the hold-down timer and this non-compliant behaviour for the AdminDown state. I just wanted to confirm that this wasn't proper behaviour. We will stick with the AdminDown behaviour Dave Katz described: "We're not running BFD right now; please act as if nothing is wrong." Bart -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Thursday, January 21, 2010 1:38 PM To: Wensley, Bart (CAR:SI23); rtg-bfd@ietf.org Subject: Re: BFD Hold Down Timers Hi Bart, See NB> below... On 1/21/10 9:51 AM, "Bart Wensley" wrote: Hi, We have been asked to support a hold down timer in our BFD implementation. The purpose of the timer would be to delay state change notifications (for a BFD session going from down to up) for the duration of the timer (which could be on the order of minutes). This would delay the re-establishment of a routing adjacency (e.g. BGP, OSPF) until the hold down timer has expired. From a search on the web, I see that Juniper has implemented this in JUNOS 8.5 and I believe this is one reason we are being asked to support it. This would be pretty straight forward, except we have also been told that the hold down timer should have the following side effects on BFD: 1. If the hold time timer is configured and a BFD session goes into the admin down state, any clients (e.g. BGP, OSPF) should treat this as the down state and break their adjacencies. NB> I am not sure what is the relation between the hold-down timer and "bfd going down". As per your description above, the hold-down is related to bfd coming up and informing clients. This is in direct conflict with draft-ietf-bfd-generic-05, section 4.1: If the session state on either the local or remote system (if known) is AdminDown, BFD has been administratively disabled, and the establishment of a control protocol adjacency MUST be allowed. 2. If the hold down timer is configured, prevent the establishment of the routing adjacency until the BFD session comes up. The implication is that if the hold down timer is not configured, the routing adjacency should be allowed before the BFD session comes up. From looking through discussions this mailing list, it seems there is some confusion as to which is the correct behaviour, although I don't think using hold down timer configuration is the right way to resolve it. NB> There was some config for isis (see draft-ietf-isis-bfd-tlv). Besides that...I don't remember any definite conclusion on what is the right way. This is third hand information, so I apologize if it is incorrect. I have searched the BFD drafts and this mailing list and I have not found any discussion of a hold down timer having these side effects. Can someone from Juniper confirm whether JUNOS behaves this way when hold down timers are used? If so: * Is this behaviour documented anywhere? NB> I will refrain from commenting on vendor specific behavior on a public forum. There is some documentation available publicly on JNPR website. - Will this be added to one of the BFD drafts? NB> Not that I am aware of. Thanks Nitin From ginsberg@cisco.com Thu Jan 21 15:51:17 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7DD28C0F5 for ; Thu, 21 Jan 2010 15:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ynHJ4zw8PLL for ; Thu, 21 Jan 2010 15:51:16 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 23DA328C0E8 for ; Thu, 21 Jan 2010 15:51:16 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADJ3WEurR7Ht/2dsb2JhbADDVJYnhDwEgyg X-IronPort-AV: E=Sophos;i="4.49,321,1262563200"; d="scan'208";a="470791618" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2010 23:51:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0LNpCpd009634; Thu, 21 Jan 2010 23:51:12 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 15:51:11 -0800 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 Subject: RE: BFD Hold Down Timers Date: Thu, 21 Jan 2010 15:51:22 -0800 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41ACB0419@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD Hold Down Timers Thread-Index: AcqawkwWaJ+l24osRXSvsaPPn3XbjQABn2FmAAGhGTAACL8d4A== References: <713043CE8B8E1348AF3C546DBE02C1B41ACB0417@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B41ACB0419@zcarhxm2.corp.nortel.com> From: "Les Ginsberg (ginsberg)" To: "Bart Wensley" , "Nitin Bahadur" X-OriginalArrivalTime: 21 Jan 2010 23:51:11.0972 (UTC) FILETIME=[9C601240:01CA9AF4] Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 23:51:17 -0000 The notion of requiring BFD session to be UP before establishing the BFD client adjacency depends upon knowledge that both sides have been configured to support BFD. Absent signalling extensions in the BFD client (such as those defined in draft-ietf-isis-bfd-tlv) this knowledge is not available. Without this knowledge inconsistent behavior can be seen. For example, consider the following sequences: Sequence #1: IGP is configured on A IGP is configured on B A-B IGP adjacency comes up BFD is configured on A Sequence #2: BFD is configured on A IGP is configured on A IGP is configured on B A-B IGP adjacency does NOT come up The state of forwarding is identical in both cases, but the state of the IGP adjacency is not. For this reason I do not find the suggested feature appealing. I would also point out that the motivation for draft-ietf-isis-bfd-tlv was issues that arise out of the lack of fate sharing between the BFD packets and IS-IS PDUs. These issues do not arise in (for example) the case of BFD and OSPFv2. Absent those issues, the IS-IS signalling extensions would not have been proposed. YMMV Les > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Bart Wensley > Sent: Thursday, January 21, 2010 11:31 AM > To: Nitin Bahadur > Cc: rtg-bfd@ietf.org; Dave Katz > Subject: RE: BFD Hold Down Timers >=20 > Nitin, >=20 > I was summarizing what we had been asked to do: > > 1. If the hold time timer is configured and a BFD session goes > > into the admin down state, any clients (e.g. BGP, OSPF) should > > treat this as the down state and break their adjacencies. >=20 > You said: > > NB> I am not sure what is the relation between the hold-down timer > > and "bfd going down". > > As per your description above, the hold-down is related to bfd > > coming up and informing clients. >=20 > There is no relation between the hold-down timer and this > non-compliant behaviour for the AdminDown state. I just wanted to > confirm that this wasn't proper behaviour. We will stick with > the AdminDown behaviour Dave Katz described: > "We're not running BFD right now; please act as if nothing is > wrong." >=20 > Bart >=20 > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Thursday, January 21, 2010 1:38 PM > To: Wensley, Bart (CAR:SI23); rtg-bfd@ietf.org > Subject: Re: BFD Hold Down Timers >=20 > Hi Bart, >=20 > See NB> below... >=20 > On 1/21/10 9:51 AM, "Bart Wensley" wrote: >=20 > Hi, >=20 > We have been asked to support a hold down timer in our BFD > implementation. The purpose of the timer would be to delay state > change notifications (for a BFD session going from down to up) > for the duration of the timer (which could be on the order of > minutes). This would delay the re-establishment of a routing > adjacency (e.g. BGP, OSPF) until the hold down timer has > expired. From a search on the web, I see that Juniper has > implemented this in JUNOS 8.5 and I believe this is one reason > we are being asked to support it. >=20 > This would be pretty straight forward, except we have also been > told that the hold down timer should have the following side > effects on BFD: >=20 > 1. If the hold time timer is configured and a BFD session goes > into the admin down state, any clients (e.g. BGP, OSPF) should > treat this as the down state and break their adjacencies. >=20 > NB> I am not sure what is the relation between the hold-down timer and > "bfd going down". > As per your description above, the hold-down is related to bfd coming > up > and informing clients. >=20 > This > is in direct conflict with draft-ietf-bfd-generic-05, section > 4.1: > If the session state on either the local or remote system > (if known) is AdminDown, BFD has been administratively > disabled, and the establishment of a control protocol > adjacency MUST be allowed. >=20 > 2. If the hold down timer is configured, prevent the > establishment of the routing adjacency until the BFD session > comes up. The implication is that if the hold down timer is > not configured, the routing adjacency should be allowed before > the BFD session comes up. > From looking through discussions > this mailing list, it seems there is some confusion as to > which is the correct behaviour, although I don't think using > hold down timer configuration is the right way to resolve it. >=20 > NB> There was some config for isis (see draft-ietf-isis-bfd-tlv). > Besides that...I don't remember any > definite conclusion on what is the right way. >=20 > This is third hand information, so I apologize if it is > incorrect. I have searched the BFD drafts and this mailing list > and I have not found any discussion of a hold down timer having > these side effects. >=20 > Can someone from Juniper confirm whether JUNOS behaves this way > when hold down timers are used? If so: >=20 > * Is this behaviour documented anywhere? >=20 > NB> I will refrain from commenting on vendor specific behavior on > a > public forum. > There is some documentation available publicly on JNPR website. >=20 > - Will this be added to one of the BFD drafts? >=20 > NB> Not that I am aware of. >=20 > Thanks > Nitin From dkatz@juniper.net Thu Jan 21 16:56:12 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440EE3A67B7 for ; Thu, 21 Jan 2010 16:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D9pVgW5SfAU for ; Thu, 21 Jan 2010 16:56:11 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 8D6633A67A3 for ; Thu, 21 Jan 2010 16:56:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS1j3oNoSYMCM/MjN3FhY6EuLvL0ypsl/@postini.com; Thu, 21 Jan 2010 16:56:07 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Thu, 21 Jan 2010 16:54:08 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 16:54:07 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 16:54:07 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 16:54:07 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o0M0s6M39445; Thu, 21 Jan 2010 16:54:06 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <35D10597-3E24-4562-A55B-2237131C9AC6@juniper.net> From: Dave Katz To: Les Ginsberg (ginsberg) In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: BFD Hold Down Timers Date: Thu, 21 Jan 2010 17:54:05 -0700 References: <713043CE8B8E1348AF3C546DBE02C1B41ACB0417@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B41ACB0419@zcarhxm2.corp.nortel.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Jan 2010 00:54:07.0328 (UTC) FILETIME=[66A9AE00:01CA9AFD] Cc: rtg-bfd@ietf.org, Bart Wensley X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 00:56:12 -0000 Well, the spec is careful to say that you need some way of knowing that BFD is in play on both ends or not. Realistically, the *vast* majority of BFD sessions will be managed at both ends by the same party, and so the a priori knowledge of whether or not BFD is desired is not at issue. For that matter, even when there are different parties, one does not bring up IGPs willy-nilly with any promiscuous router that flounces along. ;-) As for the example, as always, misconfigurations are problematic, and this is certainly not the worst thing that happens whens somebody screws up a config. More plausibly, things will work the same way in both examples if BFD is actually being configured on both ends, and the end state is identical even if you choose the maximally pessimal ordering (say, sequence #2, but configure BFD on B at the very end...) --Dave On Jan 21, 2010, at 4:51 PM, Les Ginsberg (ginsberg) wrote: > The notion of requiring BFD session to be UP before establishing the > BFD > client adjacency depends upon knowledge that both sides have been > configured to support BFD. Absent signalling extensions in the BFD > client (such as those defined in draft-ietf-isis-bfd-tlv) this > knowledge > is not available. Without this knowledge inconsistent behavior can be > seen. For example, consider the following sequences: > > Sequence #1: > IGP is configured on A > IGP is configured on B > A-B IGP adjacency comes up > BFD is configured on A > > Sequence #2: > BFD is configured on A > IGP is configured on A > IGP is configured on B > A-B IGP adjacency does NOT come up > > The state of forwarding is identical in both cases, but the state of > the > IGP adjacency is not. > > For this reason I do not find the suggested feature appealing. > > I would also point out that the motivation for draft-ietf-isis-bfd-tlv > was issues that arise out of the lack of fate sharing between the BFD > packets and IS-IS PDUs. These issues do not arise in (for example) the > case of BFD and OSPFv2. Absent those issues, the IS-IS signalling > extensions would not have been proposed. > > YMMV > > Les > >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of Bart Wensley >> Sent: Thursday, January 21, 2010 11:31 AM >> To: Nitin Bahadur >> Cc: rtg-bfd@ietf.org; Dave Katz >> Subject: RE: BFD Hold Down Timers >> >> Nitin, >> >> I was summarizing what we had been asked to do: >>> 1. If the hold time timer is configured and a BFD session goes >>> into the admin down state, any clients (e.g. BGP, OSPF) should >>> treat this as the down state and break their adjacencies. >> >> You said: >>> NB> I am not sure what is the relation between the hold-down timer >>> and "bfd going down". >>> As per your description above, the hold-down is related to bfd >>> coming up and informing clients. >> >> There is no relation between the hold-down timer and this >> non-compliant behaviour for the AdminDown state. I just wanted to >> confirm that this wasn't proper behaviour. We will stick with >> the AdminDown behaviour Dave Katz described: >> "We're not running BFD right now; please act as if nothing is >> wrong." >> >> Bart >> >> -----Original Message----- >> From: Nitin Bahadur [mailto:nitinb@juniper.net] >> Sent: Thursday, January 21, 2010 1:38 PM >> To: Wensley, Bart (CAR:SI23); rtg-bfd@ietf.org >> Subject: Re: BFD Hold Down Timers >> >> Hi Bart, >> >> See NB> below... >> >> On 1/21/10 9:51 AM, "Bart Wensley" wrote: >> >> Hi, >> >> We have been asked to support a hold down timer in our BFD >> implementation. The purpose of the timer would be to delay state >> change notifications (for a BFD session going from down to up) >> for the duration of the timer (which could be on the order of >> minutes). This would delay the re-establishment of a routing >> adjacency (e.g. BGP, OSPF) until the hold down timer has >> expired. From a search on the web, I see that Juniper has >> implemented this in JUNOS 8.5 and I believe this is one reason >> we are being asked to support it. >> >> This would be pretty straight forward, except we have also been >> told that the hold down timer should have the following side >> effects on BFD: >> >> 1. If the hold time timer is configured and a BFD session goes >> into the admin down state, any clients (e.g. BGP, OSPF) should >> treat this as the down state and break their adjacencies. >> >> NB> I am not sure what is the relation between the hold-down timer >> and >> "bfd going down". >> As per your description above, the hold-down is related to bfd coming >> up >> and informing clients. >> >> This >> is in direct conflict with draft-ietf-bfd-generic-05, section >> 4.1: >> If the session state on either the local or remote system >> (if known) is AdminDown, BFD has been administratively >> disabled, and the establishment of a control protocol >> adjacency MUST be allowed. >> >> 2. If the hold down timer is configured, prevent the >> establishment of the routing adjacency until the BFD session >> comes up. The implication is that if the hold down timer is >> not configured, the routing adjacency should be allowed before >> the BFD session comes up. >> From looking through discussions >> this mailing list, it seems there is some confusion as to >> which is the correct behaviour, although I don't think using >> hold down timer configuration is the right way to resolve it. >> >> NB> There was some config for isis (see draft-ietf-isis-bfd-tlv). >> Besides that...I don't remember any >> definite conclusion on what is the right way. >> >> This is third hand information, so I apologize if it is >> incorrect. I have searched the BFD drafts and this mailing list >> and I have not found any discussion of a hold down timer having >> these side effects. >> >> Can someone from Juniper confirm whether JUNOS behaves this way >> when hold down timers are used? If so: >> >> * Is this behaviour documented anywhere? >> >> NB> I will refrain from commenting on vendor specific behavior on >> a >> public forum. >> There is some documentation available publicly on JNPR website. >> >> - Will this be added to one of the BFD drafts? >> >> NB> Not that I am aware of. >> >> Thanks >> Nitin > > From ginsberg@cisco.com Fri Jan 22 08:46:30 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AEB3A6A7C for ; Fri, 22 Jan 2010 08:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd6B3b0s4vu9 for ; Fri, 22 Jan 2010 08:46:29 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 22EAE3A6A6E for ; Fri, 22 Jan 2010 08:46:29 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJtlWUurRN+K/2dsb2JhbADCHZYrhDwEgyE X-IronPort-AV: E=Sophos;i="4.49,324,1262563200"; d="scan'208";a="138255203" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 22 Jan 2010 16:46:25 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0MGkPtO003808; Fri, 22 Jan 2010 16:46:25 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 08:46:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: APbM B8ST EDdJ FarM SKbX Tw2m Ulks YtEG aTJO eUw6 eWCS gFZO iJJ5 i2MB nrGc wAAG; 4; YgBhAHIAdAB3AEAAbgBvAHIAdABlAGwALgBjAG8AbQA7AGQAawBhAHQAegBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA7AG4AaQB0AGkAbgBiAEAAagB1AG4AaQBwAGUAcgAuAG4AZQB0ADsAcgB0AGcALQBiAGYAZABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {25A6B097-25FE-4542-AC79-1C2CEA16B59E}; ZwBpAG4AcwBiAGUAcgBnAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Fri, 22 Jan 2010 16:46:11 GMT; UgBFADoAIABCAEYARAAgAEgAbwBsAGQAIABEAG8AdwBuACAAVABpAG0AZQByAHMA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {25A6B097-25FE-4542-AC79-1C2CEA16B59E} Content-class: urn:content-classes:message Subject: RE: BFD Hold Down Timers Date: Fri, 22 Jan 2010 08:46:11 -0800 Message-ID: In-Reply-To: <35D10597-3E24-4562-A55B-2237131C9AC6@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD Hold Down Timers Thread-Index: Acqa/a6oaXt/ghoURsS87e/B7CmGcQAgxcUg References: <713043CE8B8E1348AF3C546DBE02C1B41ACB0417@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B41ACB0419@zcarhxm2.corp.nortel.com> <35D10597-3E24-4562-A55B-2237131C9AC6@juniper.net> From: "Les Ginsberg (ginsberg)" To: "Dave Katz" X-OriginalArrivalTime: 22 Jan 2010 16:46:24.0858 (UTC) FILETIME=[6F48DBA0:01CA9B82] Cc: rtg-bfd@ietf.org, Bart Wensley X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:46:30 -0000 Dave - > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Thursday, January 21, 2010 4:54 PM > To: Les Ginsberg (ginsberg) > Cc: Bart Wensley; Nitin Bahadur; rtg-bfd@ietf.org > Subject: Re: BFD Hold Down Timers >=20 > Well, the spec is careful to say that you need some way of knowing > that BFD is in play on both ends or not. I have no problem w the spec in this regard. >=20 > Realistically, the *vast* majority of BFD sessions will be managed at > both ends by the same party, and so the a priori knowledge of whether > or not BFD is desired is not at issue. >=20 > For that matter, even when there are different parties, one does not > bring up IGPs willy-nilly with any promiscuous router that flounces > along. ;-) >=20 > As for the example, as always, misconfigurations are problematic, and > this is certainly not the worst thing that happens whens somebody > screws up a config. More plausibly, things will work the same way in > both examples if BFD is actually being configured on both ends, and > the end state is identical even if you choose the maximally pessimal > ordering (say, sequence #2, but configure BFD on B at the very end...) > The more substantive point in my post was that the motivation for wanting to prevent the IGP adjacency from coming up BEFORE BFD session is established is the lack of fate sharing of the IGP PDUs/packets and the BFD packets. In the case of IS-IS this lack of fate sharing has been demonstrated to cause problems in the real world - hence draft-ietf-isis-bfd-tlv. There are other cases to which the same issues are applicable (e.g. OSPFv3 support for IPv4) - but I am not aware of issues in cases where the same network layer protocol is used for IGP and BFD (e.g. OSPFv2). Given the widespread deployment of BFD support which does NOT require the BFD session to be up prior to IGP adjacency establishment, the introduction of implementations which require this in the absence of IGP signalling of BFD support does cause interoperability problems. Les =20 =20 > --Dave >=20 > On Jan 21, 2010, at 4:51 PM, Les Ginsberg (ginsberg) wrote: >=20 > > The notion of requiring BFD session to be UP before establishing the > > BFD > > client adjacency depends upon knowledge that both sides have been > > configured to support BFD. Absent signalling extensions in the BFD > > client (such as those defined in draft-ietf-isis-bfd-tlv) this > > knowledge > > is not available. Without this knowledge inconsistent behavior can be > > seen. For example, consider the following sequences: > > > > Sequence #1: > > IGP is configured on A > > IGP is configured on B > > A-B IGP adjacency comes up > > BFD is configured on A > > > > Sequence #2: > > BFD is configured on A > > IGP is configured on A > > IGP is configured on B > > A-B IGP adjacency does NOT come up > > > > The state of forwarding is identical in both cases, but the state of > > the > > IGP adjacency is not. > > > > For this reason I do not find the suggested feature appealing. > > > > I would also point out that the motivation for draft-ietf-isis-bfd- > tlv > > was issues that arise out of the lack of fate sharing between the BFD > > packets and IS-IS PDUs. These issues do not arise in (for example) > the > > case of BFD and OSPFv2. Absent those issues, the IS-IS signalling > > extensions would not have been proposed. > > > > YMMV > > > > Les > > > >> -----Original Message----- > >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > >> Behalf Of Bart Wensley > >> Sent: Thursday, January 21, 2010 11:31 AM > >> To: Nitin Bahadur > >> Cc: rtg-bfd@ietf.org; Dave Katz > >> Subject: RE: BFD Hold Down Timers > >> > >> Nitin, > >> > >> I was summarizing what we had been asked to do: > >>> 1. If the hold time timer is configured and a BFD session goes > >>> into the admin down state, any clients (e.g. BGP, OSPF) should > >>> treat this as the down state and break their adjacencies. > >> > >> You said: > >>> NB> I am not sure what is the relation between the hold-down timer > >>> and "bfd going down". > >>> As per your description above, the hold-down is related to bfd > >>> coming up and informing clients. > >> > >> There is no relation between the hold-down timer and this > >> non-compliant behaviour for the AdminDown state. I just wanted to > >> confirm that this wasn't proper behaviour. We will stick with > >> the AdminDown behaviour Dave Katz described: > >> "We're not running BFD right now; please act as if nothing is > >> wrong." > >> > >> Bart > >> > >> -----Original Message----- > >> From: Nitin Bahadur [mailto:nitinb@juniper.net] > >> Sent: Thursday, January 21, 2010 1:38 PM > >> To: Wensley, Bart (CAR:SI23); rtg-bfd@ietf.org > >> Subject: Re: BFD Hold Down Timers > >> > >> Hi Bart, > >> > >> See NB> below... > >> > >> On 1/21/10 9:51 AM, "Bart Wensley" wrote: > >> > >> Hi, > >> > >> We have been asked to support a hold down timer in our BFD > >> implementation. The purpose of the timer would be to delay state > >> change notifications (for a BFD session going from down to up) > >> for the duration of the timer (which could be on the order of > >> minutes). This would delay the re-establishment of a routing > >> adjacency (e.g. BGP, OSPF) until the hold down timer has > >> expired. From a search on the web, I see that Juniper has > >> implemented this in JUNOS 8.5 and I believe this is one reason > >> we are being asked to support it. > >> > >> This would be pretty straight forward, except we have also been > >> told that the hold down timer should have the following side > >> effects on BFD: > >> > >> 1. If the hold time timer is configured and a BFD session goes > >> into the admin down state, any clients (e.g. BGP, OSPF) should > >> treat this as the down state and break their adjacencies. > >> > >> NB> I am not sure what is the relation between the hold-down timer > >> and > >> "bfd going down". > >> As per your description above, the hold-down is related to bfd > coming > >> up > >> and informing clients. > >> > >> This > >> is in direct conflict with draft-ietf-bfd-generic-05, section > >> 4.1: > >> If the session state on either the local or remote system > >> (if known) is AdminDown, BFD has been administratively > >> disabled, and the establishment of a control protocol > >> adjacency MUST be allowed. > >> > >> 2. If the hold down timer is configured, prevent the > >> establishment of the routing adjacency until the BFD session > >> comes up. The implication is that if the hold down timer is > >> not configured, the routing adjacency should be allowed before > >> the BFD session comes up. > >> From looking through discussions > >> this mailing list, it seems there is some confusion as to > >> which is the correct behaviour, although I don't think using > >> hold down timer configuration is the right way to resolve it. > >> > >> NB> There was some config for isis (see draft-ietf-isis-bfd-tlv). > >> Besides that...I don't remember any > >> definite conclusion on what is the right way. > >> > >> This is third hand information, so I apologize if it is > >> incorrect. I have searched the BFD drafts and this mailing list > >> and I have not found any discussion of a hold down timer having > >> these side effects. > >> > >> Can someone from Juniper confirm whether JUNOS behaves this way > >> when hold down timers are used? If so: > >> > >> * Is this behaviour documented anywhere? > >> > >> NB> I will refrain from commenting on vendor specific behavior > on > >> a > >> public forum. > >> There is some documentation available publicly on JNPR website. > >> > >> - Will this be added to one of the BFD drafts? > >> > >> NB> Not that I am aware of. > >> > >> Thanks > >> Nitin > > > > From Adrian.Farrel@huawei.com Sat Jan 30 06:28:31 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71023A67B0 for ; Sat, 30 Jan 2010 06:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6q+vCVRbbgN for ; Sat, 30 Jan 2010 06:28:31 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 0E3B53A6405 for ; Sat, 30 Jan 2010 06:28:31 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX200KEYDK90T@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Sat, 30 Jan 2010 06:28:57 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KX200L0CDK34X@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Sat, 30 Jan 2010 06:28:57 -0800 (PST) Date: Sat, 30 Jan 2010 14:28:41 +0000 From: Adrian Farrel Subject: Progressing draft-ietf-bfd-base and IPR concerns To: rtg-bfd@ietf.org Message-id: <013C868A718045AB976371E6C2A5848E@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 14:28:31 -0000 Hi BFD working group, Ross and I have done a shuffle for AD shepherding of the base BFD draft in order to avoid any dominance by a single vendor. Looking at the IPR disclosures page for this draft (https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-bfd-base) I see two disclosures that claim to be related to this work. I am also aware of rumours that there may be more IPR out there that isrelated to this work that people might like to disclose.This email is to give the BFD working group a two week period (ending Sunday14th February) to raise any further IPR disclosures relating to this draft.1. Where possible, please file a disclosure using the tools at http://www.ietf.org/ipr/file-disclosure2. If you know of IPR held by a third party, consider notifying the IETF through the same web pages.3. If you believe that IPR exists but that you are unable to disclose or notify by following the previous two points, please consider whether youcan send a note to the BFD mailing list to warn the working group about potential IPR.Can I recommend that all people with concerns about IPR look at the IETF'sIPR Policy page http://www. ietf.org