Re: [trill] TRILL BFD draft and RFC 6213

[Donald Eastlake <[e-mail]>]

Hi Les,

Thanks for the comments. See below

On Wed, Feb 13, 2013 at 1:42 AM, Les Ginsberg (ginsberg)
<[e-mail]> wrote:
> 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>

I believe the reference to RFC 6213 was primarily because that is
where the BFD Enabled TLV is defined.

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

I agree that, when BFD is in use, it should be a pre-condition for an
adjacency in TRILL to enter the Report state and that RFC 6327 should
be revised to reflect that.

> 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 believe that, as you point out, since TRILL use of BFD is just
starting, it can be assumed that the BFD Enabled TLV will be used.

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

OK. I believe this can be incorporated into an RFC 6327bis.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Thanx.
>
>     Les