[trill] TRILL BFD draft and RFC 6213

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 13 February 2013 06:42 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6CD7821F89AA for <trill@ietfa.amsl.com>; Tue, 12 Feb 2013 22:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id l6WsBnYoaeBa for <trill@ietfa.amsl.com>; Tue, 12 Feb 2013 22:42:23 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4B9DD21F891D for <trill@ietf.org>; Tue, 12 Feb 2013 22:42:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2655; q=dns/txt; s=iport; t=1360737743; x=1361947343; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=AGBcstIbtzaw637q9vNTmtB7CY34My0erReKg3CZNxg=; b=DTRUGcBzoCe+ms6Z/DEOxWklpAr8FNOaYkl70vutLRJBqFbNeTn2RPtI Fo9IrjEr9fIz/Yj1b60AiXHKYq9ZRq1+5S9rlTFKD0ZQqVV8/ybBDRWK4 sMeGtweSZGovRhKcyxDZlRcRp9JhLylw29MtUz+0q5gqVevL/U9yjI4bo Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAGU1G1GtJXHA/2dsb2JhbABEwG4Wc4IhAQQ6PxIBFhQUQiYBBA4NiAq/V5EkYQOmd4MGgWkHNw
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; d="scan'208";a="176502921"
Received: from rcdn-core2-5.cisco.com ([]) by rcdn-iport-6.cisco.com with ESMTP; 13 Feb 2013 06:42:06 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com []) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1D6g6jL021996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 06:42:06 GMT
Received: from xmb-aln-x02.cisco.com ([]) by xhc-aln-x04.cisco.com ([]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 00:42:06 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Thread-Topic: TRILL BFD draft and RFC 6213
Thread-Index: Ac4JsgKkFLEjd0LuTIe537xTBjgKGA==
Date: Wed, 13 Feb 2013 06:42:05 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F1326FE03@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: [trill] TRILL BFD draft and RFC 6213
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2013 06:42:24 -0000

draft-ietf-trill-rbridge-bfd-07.txt states in Section 3.1 states:

For neighbor RBridges RB1 and RB2, each RBridge sends one-hop TRILL
   BFD Control frames to the other only if TRILL IS-IS has detected bi-
   directional connectivity, that is, the adjacency is in the Two-Way or
   Report state [RFC6327] and both RBridges indicate support of TRILL
   BFD is enabled.  The BFD Enabled TLV is used to indicate this as
   specified in [RFC6213].
<end snip>

The BFD Enabled TLV was introduced to address the lack of fate sharing between IS-IS PDUs and BFD packets. When this is the case, the preferred use of BFD is as a necessary condition for a topology specific adjacency to be usable - rather than as simply a fast failure detection mechanism. RFC 6213 therefore introduces (in a backwards compatible way) changes in the ISO 10589 adjacency state machine such that an adjacency is NOT UP and/or the topology specific IS neighbor is NOT advertised in LSPs unless the BFD session is up. The logical equivalent of this in RFC 6327 states would be to make the BFD session UP requirement apply to the Report state.

The wording in the draft seems to be stating something different. It is stating that an Rbridge should not send BFD control frames until after the following two conditions have been verified:

1)Two-Way or Report state has been achieved
2)Neighbor BFD enabled support has been indicated by receipt of the BFD enabled TLV

Defined in this way you differ from RFC 6213 usage in significant ways.

You allow the adjacency to reach full operational state (including IS neighbor advertisement in LSPs) w/o requiring the BFD session to be UP. This means you do not have fate sharing protection. Now, if this is because you believe there is no fate sharing issue in TRILL, then frankly you don't really need RFC 6213 functionality. The only value add the BFD enabled TLV provides is a small optimization in that you won't needlessly send BFD packets to a neighbor who does not support BFD. This comes at the cost of not being able to use BFD w a neighbor which supports BFD but does not send the BFD enabled TLV. Perhaps this also is not a concern since TRILL use of BFD is only now being defined and so it can be expected that the BFD enabled TLV will be sent by any Rbridge which supports TRILL BFD.

I do not object to your revised use of the BFD enabled TLV, but I do think the draft would be improved by explicitly stating the ways in which TRILL BFD usage of the BFD enabled TLV differs from RFC 6213 and the reasons why.