OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode
draft-ietf-lsr-ospf-bfd-strict-mode-10

# Éric Vyncke, INT AD, comments for draft-ietf-lsr-ospf-bfd-strict-mode-09
CC @evyncke

Thank you for the work put into this document. It is short, clear, and useful (hence my YES).

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 3 

Suggest to move section 3 (Local Interface IPv4 Address TLV) as a subsection of section 4.1 (OSPFv3 IPv4 Address-Family Specifics) as, at least for me, the reader cannot understand the use of section 3 before reading section 4.1

As I am not an OSPFv3 expert, the following question is possibly irrelevant, but can the IPv4 address be a link-local (i.e., 169.254/16)?

### Section 4.1

```
   ... In most deployments of
   OSPFv3 IPv4 AF, it is required that BFD is used to monitor and verify
   IPv4 data plane connectivity between the routers on the link and,
   hence, the BFD session is setup using IPv4 neighbor addresses. 
```

The text is a little unclear whether an IPv6 BFD session is also required.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

Thanks for this document.  I think that what is being proposed here is useful.

A few minor/nit comments that may improve this document.

Minor level comments:

(1) p 6, sec 5.  Operations & Management Considerations

Not for this document, and ss per my other OSPF ballots, I assume that the LSR WG will update the OSPF YANG model will be updated to accommodate this feature.


(2) p 6, sec 5.  Operations & Management Considerations

   In network deployments with noisy or degraded links with intermittent
   packet loss, BFD sessions may flap resulting in OSPF adjacency flaps.
   This in turn may cause routing churn.  The use of OSPF BFD strict-
   mode along with mechanisms such as hold-down (a delay in the initial
   OSPF adjacency bringup following BFD session establishment) and/or
   dampening (a delay in the OSPF adjacency bringup following failure
   detected by BFD) may help reduce the frequency of adjacency flaps and
   therefore reduce the associated routing churn.  The details of these
   mechanisms are outside the scope of this document.

For my understanding, is the expectation that if a device supports this feature then it would (or is that SHOULD) be enabled automatically?



Nit level comments:

(3) p 6, sec 6.  Backward Compatibility

   established successfully.  Implementations MAY provide a local
   configuration option to enable BFD without the strict-mode which
   results in the router not advertising the B-bit and BFD operation
   being performed in the same way as prior to this specification.

I find the text about enable BFD without the strict-mode to be slightly unclear, since presumably it is the OSPF interactions with BFD that the configuration is referred to, rather than BFD itself.  Perhaps changing "strict-mode" to "OSPF BFD strict-mode" might be clearer.

Thank you for this document.

When I started reading this document / read the Abstract, I must admit I thought "This is a silly idea, and smacks of creeping featuritis and premature optimization. This is an already solved problem - you bring up OSPF and *then* use that to signal that you want BFD...."
and then I actually read the Introduction section and the use-case / utility became clear...

My only question (and I'm suspecting it has already been discussed) if is there should actually be some (small) delay after the BFD session establishment to allow the interface to "settle" / give BFD a second or two to figure out if the link is actually "stable" - having BFD come up and then immediately bringing up the adjacency, only to have BFD pull it down 10ms later doesn't seem to solve the issue really... unless it is expected that the OSPF exchange is sufficiently slow that BFD would detect it before OSPF is actually working?