IETF Logo Mail Archive

draft-ietf-bfd-generic-05, adjacency establishment (section 4.1, 10.1.1)

"Johannes Resch" <jr@xor.at> Fri, 11 December 2009 14:14 UTC

Return-Path: <jr@xor.at>
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 <rtg-bfd@core3.amsl.com>; 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 <rtg-bfd@core3.amsl.com>; 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 <rtg-bfd@ietf.org>; 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 <rtg-bfd@ietf.org>; 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 <rtg-bfd@ietf.org>; 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 <rtg-bfd@ietf.org>; 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
Subject: draft-ietf-bfd-generic-05, adjacency establishment (section 4.1, 10.1.1)
From: Johannes Resch <jr@xor.at>
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" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=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..

v2.23.0 | Report a Bug | By Email