From jr@xor.at Fri Dec 11 06:14:46 2009 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 BC4A93A68F5 for ; Fri, 11 Dec 2009 06:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.984 X-Spam-Level: X-Spam-Status: No, score=0.984 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 Xe+au-ZkJ+M5 for ; Fri, 11 Dec 2009 06:14:42 -0800 (PST) Received: from mail.xor.at (mail.xor.at [78.47.252.92]) by core3.amsl.com (Postfix) with ESMTP id 79BE53A6944 for ; Fri, 11 Dec 2009 06:14:40 -0800 (PST) Received: from mail.xor.at (localhost [127.0.0.1]) by mail.xor.at (Postfix) with SMTP id E2B1154C1DB for ; Fri, 11 Dec 2009 15:14:23 +0100 (CET) Received: from mail.xor.at (localhost [127.0.0.1]) by mail.xor.at (Postfix) with ESMTP id CE3FE54C8C5 for ; Fri, 11 Dec 2009 15:14:23 +0100 (CET) Received: from and.xor.at (webmail.xor.at [192.168.140.10]) by mail.xor.at (Postfix) with ESMTP id B7A1A54C1DB for ; Fri, 11 Dec 2009 15:14:23 +0100 (CET) Received: from 195.112.95.126 (SquirrelMail authenticated user joschi) by and.xor.at with HTTP; Fri, 11 Dec 2009 15:14:23 +0100 (CET) Message-ID: <40db7bd90095815924982b4b8c8017bd.squirrel@and.xor.at> Date: Fri, 11 Dec 2009 15:14:23 +0100 (CET) Subject: draft-ietf-bfd-generic-05, adjacency establishment (section 4.1, 10.1.1) From: "Johannes Resch" To: rtg-bfd@ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-AV-Checked: ClamAV using ClamSMTP Content-Transfer-Encoding: quoted-printable 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, 11 Dec 2009 14:14:46 -0000 Hi all, I'm currently seeing a problem that might be an interop issue between two vendors concerning the adjacency formation using BFD with OSPF as client. Trying to determine which side behaves "correct", I've got the impression that the wording in draft-ietf-bfd-generic-05, section 4.1 and/or 10.1.1 is not quite specific to define the following points: 1. when an implementation should actively start sending BFD protocol packets during the multiple steps of IGP adjacency formation 2. when an implementation should accept BFD protocol traffic from an IGP neighbor during the multiple steps of IGP adjacency formation The specific problem I'm seeing is that vendor1 already triggers BFD in 2-way phase, while vendor2 will neither send nor accept BFD traffic in that phase. The result is that the OSPF state on vendor1 device will not proceed to exstart/exchange state and remains in "BFDdown" state forever, while vendor2 toggles between exstart and down (after reaching retransmission timeouts for DD packets) Did I miss some other documents where these points are spelled out in a more detailed fashion? Is this something that has been discussed before? Best regards, -jr PS: I would also be particularly interested if Cisco folks could comment on what behavior is correct from their POV.. From albright@cisco.com Fri Dec 11 06:46:32 2009 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 95D4B3A6934 for ; Fri, 11 Dec 2009 06:46:32 -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 TJuNPlSekGKv for ; Fri, 11 Dec 2009 06:46:31 -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 BE42F28B797 for ; Fri, 11 Dec 2009 06:46:31 -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: ApoEALvpIUurR7Hu/2dsb2JhbAC+UZcphCsEgWM X-IronPort-AV: E=Sophos;i="4.47,382,1257120000"; d="scan'208";a="448159241" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Dec 2009 14:46:17 +0000 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBBEkHeI024797; Fri, 11 Dec 2009 14:46:17 GMT Received: (from albright@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA24569; Fri, 11 Dec 2009 06:45:22 -0800 (PST) Date: Fri, 11 Dec 2009 6:45:22 PST From: Bob Albrightson To: "Johannes Resch" Subject: Re: draft-ietf-bfd-generic-05, adjacency establishment (section 4.1, 10.1.1) In-Reply-To: Your message of Fri, 11 Dec 2009 15:14:23 +0100 (CET) Message-ID: 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, 11 Dec 2009 14:46:32 -0000 Unless I'm missing something, it seems to me if a BFD client has not asked BFD to bring up a session, then any three way handshake in an attempt to bring up a BFD session should fail. OSPF should not be relying on BFD to come up before bring up its sessions. BFD clients need to bring up their sessions first before asking BFD to monitor the peer. -bob > Hi all, > > I'm currently seeing a problem that might be an interop issue between two > vendors concerning the adjacency formation using BFD with OSPF as client. > > Trying to determine which side behaves "correct", I've got the impression > that the wording in draft-ietf-bfd-generic-05, section 4.1 and/or 10.1.1 > is not quite specific to define the following points: > > 1. when an implementation should actively start sending BFD protocol > packets during the multiple steps of IGP adjacency formation > 2. when an implementation should accept BFD protocol traffic from an IGP > neighbor during the multiple steps of IGP adjacency formation > > The specific problem I'm seeing is that vendor1 already triggers BFD in > 2-way phase, while vendor2 will neither send nor accept BFD traffic in > that phase. > The result is that the OSPF state on vendor1 device will not proceed to > exstart/exchange state and remains in "BFDdown" state forever, while > vendor2 toggles between exstart and down (after reaching retransmission > timeouts for DD packets) > > Did I miss some other documents where these points are spelled out in a > more detailed fashion? Is this something that has been discussed before? > > > Best regards, > -jr > > PS: I would also be particularly interested if Cisco folks could comment > on what behavior is correct from their POV.. > From vph@iki.fi Fri Dec 11 07:37:03 2009 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 DD0383A687B for ; Fri, 11 Dec 2009 07:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] 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 fjLW9mjwRj5L for ; Fri, 11 Dec 2009 07:37:02 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id C95C83A683B for ; Fri, 11 Dec 2009 07:37:02 -0800 (PST) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 296A5C55D2; Fri, 11 Dec 2009 10:36:50 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 11 Dec 2009 10:36:50 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=smtpout; bh=tQQkPOg4m0IAMClgQdejqC/xh7Y=; b=hrYmg2juQMTOq3b13iRcK+U2ipqVkkS4A3CTvTuODhGo+WIfjhOfSqUwRQ0P9m8Qa0F1JJZ6AfXg9Fgwg0TFwY5yxARpQskCAOoNtn2KNjZL3z4JgJUQ/1GKrMb3D03lvUSocb+atbYIr0iv78yFw2Xq+iwNuX40QcLaO5gR6fk= X-Sasl-enc: v0IxEb78JejxNULYkqbVB7Map5a4sOoZguAkOB5IKEoK 1260545809 Received: from ogier.homeunix.net (a91-154-109-15.elisa-laajakaista.fi [91.154.109.15]) by mail.messagingengine.com (Postfix) with ESMTPSA id 40B8B4ABE25; Fri, 11 Dec 2009 10:36:49 -0500 (EST) Date: Fri, 11 Dec 2009 17:36:46 +0200 From: Ville Hallivuori To: Bob Albrightson Subject: Re: draft-ietf-bfd-generic-05, adjacency establishment (section 4.1, 10.1.1) Message-ID: <20091211153646.GA88040@ogier.homeunix.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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, 11 Dec 2009 15:37:04 -0000 Hello all, I don't see how OSPF could be brought up before BFD session is up. If user has configured BFD monitoring as a prerequisite, then OSPF clearly must keep any neighbors that do not have BFD sessions up in a state that does not permit traffic forwarding. Proper state seems to be Init. If implementation were to take a more relaxed approach and negotiate OSPF before BFD session is up, it would risk longer detection times (up to OSPF dead timer, usually 40 seconds): - Until BFD session is brought up - Forever, if neighbor does not support BFD I do agree with Bob that BFD negotiation must not succeed until both ends have decided to form a BFD adjacency. IETF documents are indeed pretty vague about this subjects. However having implemented this once, it seems to me that the only fool proof process is to: 1) Send OSPF hellos normally 2) Receive OSPF hellos normally 3) When new OSPF neighbor is detected (and BFD is configured), trigger BFD session formation. 4) Until BFD session is up, keep neighbor in Init -state On Fri, Dec 11, 2009 at 06:45:22AM -0800, Bob Albrightson wrote: > Unless I'm missing something, it seems to me if a BFD client has not > asked BFD to bring up a session, then any three way handshake in an > attempt to bring up a BFD session should fail. > > OSPF should not be relying on BFD to come up before bring up its > sessions. BFD clients need to bring up their sessions first before > asking BFD to monitor the peer. > > -bob > > > Hi all, > > > > I'm currently seeing a problem that might be an interop issue between two > > vendors concerning the adjacency formation using BFD with OSPF as client. > > > > Trying to determine which side behaves "correct", I've got the impression > > that the wording in draft-ietf-bfd-generic-05, section 4.1 and/or 10.1.1 > > is not quite specific to define the following points: > > > > 1. when an implementation should actively start sending BFD protocol > > packets during the multiple steps of IGP adjacency formation > > 2. when an implementation should accept BFD protocol traffic from an IGP > > neighbor during the multiple steps of IGP adjacency formation > > > > The specific problem I'm seeing is that vendor1 already triggers BFD in > > 2-way phase, while vendor2 will neither send nor accept BFD traffic in > > that phase. > > The result is that the OSPF state on vendor1 device will not proceed to > > exstart/exchange state and remains in "BFDdown" state forever, while > > vendor2 toggles between exstart and down (after reaching retransmission > > timeouts for DD packets) > > > > Did I miss some other documents where these points are spelled out in a > > more detailed fashion? Is this something that has been discussed before? > > > > > > Best regards, > > -jr > > > > PS: I would also be particularly interested if Cisco folks could comment > > on what behavior is correct from their POV.. > > > > -- [Ville Hallivuori][vph@iki.fi][http://www.iki.fi/vph/] [ID 30EC5DF0][FP20=3B02 94F1 FF6F 9CD0 EC81 0FAE 5B3B 3D21 30EC 5DF0] From dkatz@juniper.net Fri Dec 11 09:24:55 2009 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 665693A69BB for ; Fri, 11 Dec 2009 09:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 7M3rqwMPE4Oi for ; Fri, 11 Dec 2009 09:24:54 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id E80053A67D3 for ; Fri, 11 Dec 2009 09:24:51 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSyKAWFEHtbS62GWnmIStfwegroRBUXVb@postini.com; Fri, 11 Dec 2009 09:24:43 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; Fri, 11 Dec 2009 09:21:41 -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); Fri, 11 Dec 2009 09:21:41 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 09:21:40 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 09:21:40 -0800 Received: from nimbus-sc.juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id nBBHLeM77797; Fri, 11 Dec 2009 09:21:40 -0800 (PST) (envelope-from dkatz@juniper.net) From: Dave Katz To: Johannes Resch In-Reply-To: <40db7bd90095815924982b4b8c8017bd.squirrel@and.xor.at> Subject: Re: draft-ietf-bfd-generic-05, adjacency establishment (section 4.1, 10.1.1) X-Priority: 3 (Normal) References: <40db7bd90095815924982b4b8c8017bd.squirrel@and.xor.at> Message-ID: <8B1CA78D-FAB9-4C5A-A1C5-2AF3FD630781@juniper.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Dec 2009 09:21:39 -0800 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Dec 2009 17:21:40.0731 (UTC) FILETIME=[6717F4B0:01CA7A86] 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, 11 Dec 2009 17:24:55 -0000 It sounds as though the confusion is partly due to my less-than- adequate wordsmithing, and partly due to OSPF's unfortunate overloading of the term "adjacency", and partly due to vendor2 not thinking through the problem to be solved too thoroughly. The intent is to trigger the BFD session as soon as the neighbor is discovered, which in the case of OSPF would be as soon as the first Hello is received from the neighbor. The verbiage in 4.1 is attempting to describe (in the case of OSPF) blocking even advancing to 2way state until the BFD session comes up--the lack of BFD should leave the OSPF neighbor stuck in Init state, subject to the caveats therein. The acceptance of BFD packets ought not to be ambiguous; if one side hasn't turned on BFD yet, it's not going to receive the packets, and if it is attempting to bring up a session, it will. I'll see if I can make an editorial change at this late date. Sorry for the confusion, --Dave On Dec 11, 2009, at 6:14 AM, Johannes Resch wrote: > Hi all, > > I'm currently seeing a problem that might be an interop issue > between two > vendors concerning the adjacency formation using BFD with OSPF as > client. > > Trying to determine which side behaves "correct", I've got the > impression > that the wording in draft-ietf-bfd-generic-05, section 4.1 and/or > 10.1.1 > is not quite specific to define the following points: > > 1. when an implementation should actively start sending BFD protocol > packets during the multiple steps of IGP adjacency formation > 2. when an implementation should accept BFD protocol traffic from an > IGP > neighbor during the multiple steps of IGP adjacency formation > > The specific problem I'm seeing is that vendor1 already triggers BFD > in > 2-way phase, while vendor2 will neither send nor accept BFD traffic in > that phase. > The result is that the OSPF state on vendor1 device will not proceed > to > exstart/exchange state and remains in "BFDdown" state forever, while > vendor2 toggles between exstart and down (after reaching > retransmission > timeouts for DD packets) > > Did I miss some other documents where these points are spelled out > in a > more detailed fashion? Is this something that has been discussed > before? > > > Best regards, > -jr > > PS: I would also be particularly interested if Cisco folks could > comment > on what behavior is correct from their POV.. > > From ginsberg@cisco.com Fri Dec 11 23:57:50 2009 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 308423A6863 for ; Fri, 11 Dec 2009 23:57:50 -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 0F9P8CcWHHNS for ; Fri, 11 Dec 2009 23:57:49 -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 3EE963A67EF for ; Fri, 11 Dec 2009 23:57:49 -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: ApoEACLbIkurRN+J/2dsb2JhbAC9eJZ9hCsEgWI X-IronPort-AV: E=Sophos;i="4.47,386,1257120000"; d="scan'208";a="118576993" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Dec 2009 07:57:32 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBC7vXsG013454; Sat, 12 Dec 2009 07:57:33 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); Fri, 11 Dec 2009 23:57:32 -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: draft-ietf-bfd-generic-05, adjacency establishment (section 4.1, 10.1.1) Date: Fri, 11 Dec 2009 23:57:27 -0800 Message-ID: In-Reply-To: <8B1CA78D-FAB9-4C5A-A1C5-2AF3FD630781@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-bfd-generic-05, adjacency establishment (section 4.1, 10.1.1) Thread-Index: Acp6htv/HGDts1BWRSOrLhWXjT6XggAeAM+w References: <40db7bd90095815924982b4b8c8017bd.squirrel@and.xor.at> <8B1CA78D-FAB9-4C5A-A1C5-2AF3FD630781@juniper.net> From: "Les Ginsberg (ginsberg)" To: "Dave Katz" , "Johannes Resch" X-OriginalArrivalTime: 12 Dec 2009 07:57:32.0937 (UTC) FILETIME=[C2A63790:01CA7B00] 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: Sat, 12 Dec 2009 07:57:50 -0000 The key issue in determining whether the IGP adjacency should be brought up before or after the BFD session is whether the IGP knows the state of BFD support both locally and on the neighbor. If BFD is either not supported or not enabled on the neighbor then waiting on BFD will prevent the IGP adjacency from coming up in situations where the adjacency SHOULD come up. This point is discussed in draft-ietf-bfd-generic-05 Section 4.1 - and seems clear to me - though Dave seems to think the wording could be improved. Section 4.1 also mentions that the control protocol could carry signaling as to the willingness to establish a BFD session - thereby enabling the IGP to correctly choose whether to block the establishment of its adjacency until the BFD session is up or not. The only defined signalling I am aware of is in draft-ietf-isis-bfd-tlv-01 Absent such a signalling mechanism, it has been standard procedure for the IGP adjacency to come up first and the BFD session to be used solely as a fast-down detection mechanism. This works well enough in cases where the control protocol packets share fate with the BFD packets - which is the case with OSPFv2 and OSPFv3 when used for IPv6. However it is not the case for IS-IS - hence the motivation for the above draft. It is also not the case when OSPFv3 is used to support IPv4. Les > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Dave Katz > Sent: Friday, December 11, 2009 9:22 AM > To: Johannes Resch > Cc: rtg-bfd@ietf.org > Subject: Re: draft-ietf-bfd-generic-05, adjacency establishment > (section 4.1,10.1.1) >=20 > It sounds as though the confusion is partly due to my less-than- > adequate wordsmithing, and partly due to OSPF's unfortunate > overloading of the term "adjacency", and partly due to vendor2 not > thinking through the problem to be solved too thoroughly. >=20 > The intent is to trigger the BFD session as soon as the neighbor is > discovered, which in the case of OSPF would be as soon as the first > Hello is received from the neighbor. The verbiage in 4.1 is > attempting to describe (in the case of OSPF) blocking even advancing > to 2way state until the BFD session comes up--the lack of BFD should > leave the OSPF neighbor stuck in Init state, subject to the caveats > therein. >=20 > The acceptance of BFD packets ought not to be ambiguous; if one side > hasn't turned on BFD yet, it's not going to receive the packets, and > if it is attempting to bring up a session, it will. >=20 > I'll see if I can make an editorial change at this late date. >=20 > Sorry for the confusion, >=20 > --Dave >=20 > On Dec 11, 2009, at 6:14 AM, Johannes Resch wrote: >=20 > > Hi all, > > > > I'm currently seeing a problem that might be an interop issue > > between two > > vendors concerning the adjacency formation using BFD with OSPF as > > client. > > > > Trying to determine which side behaves "correct", I've got the > > impression > > that the wording in draft-ietf-bfd-generic-05, section 4.1 and/or > > 10.1.1 > > is not quite specific to define the following points: > > > > 1. when an implementation should actively start sending BFD protocol > > packets during the multiple steps of IGP adjacency formation > > 2. when an implementation should accept BFD protocol traffic from an > > IGP > > neighbor during the multiple steps of IGP adjacency formation > > > > The specific problem I'm seeing is that vendor1 already triggers BFD > > in > > 2-way phase, while vendor2 will neither send nor accept BFD traffic > in > > that phase. > > The result is that the OSPF state on vendor1 device will not proceed > > to > > exstart/exchange state and remains in "BFDdown" state forever, while > > vendor2 toggles between exstart and down (after reaching > > retransmission > > timeouts for DD packets) > > > > Did I miss some other documents where these points are spelled out > > in a > > more detailed fashion? Is this something that has been discussed > > before? > > > > > > Best regards, > > -jr > > > > PS: I would also be particularly interested if Cisco folks could > > comment > > on what behavior is correct from their POV.. > > > >