[trill] TRILL BFD draft and RFC 6213

["Les Ginsberg (ginsberg)" <[e-mail]>]

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

<snip>
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.

Thanx.

    Les