Dear Authors, et al.,
thank you for this well-written document. The mechanism described in the
draft is, in my opinion, useful and will save considerable efforts of the
operator. I have several questions and comments listed below:
- Would the introduction of Unsolicited mode make this draft updating
RFC 5881?
- I didn't find any new values of BFD parameters that distinguish an
unsolicited BFD session from the "classic single-hop" session. Do you think
such a distinction could be useful to an operator?
- In Section 2 stated
On the passive side, the "unsolicited BFD" SHOULD be configured
explicitly on an interface.
Does that imply that it MAY be configured node-wide? I think it would be
helpful to explicitly list the alternative option.
- The fourth paragraph in Section 2 explains the handling of the first
BFD control packet with Your Discriminator == 0, i.e., "it does not find an
existing session with the same source address". What happens if the
matching BFD session has been found?
- A BFD session then created "based on the source address and
destination address". Does that mean that there will be only one session
with the same source address despite different destination addresses
listed? If that is the case, could the BFD session be associated only with
the source IP address of the received BFD control packet?
- Between creating the BFD session (above) and
It would
then start sending the BFD Control packets and perform necessary
procedure for bringing up, maintaining and tearing down the BFD
session.
the local BFD system assigns My Discriminator to the session. Though it is
standard (RFC 5880) step, it might be useful to mention it.
- Does "an established BFD session goes down" mean the state is Down and
only Down or it also includes AdminDown state?
- Furter stated
the
passive side would stop sending BFD Control packets and delete the
BFD session created until the BFD Control packets is initiated by the
active side again.
Probably some normative language be helpful to replace "would". And is the
stop applied immediately or after some grace period? The same question
about the deletion of BFD parameters and the FSM (probably this is left to
the implementation).
- I'd admit got confused by the last paragraph in Section 2:
The "Passive role" may change to the "Active role" when a local
client registers for the same BFD session ...
Is it normative MAY? Does that mean that the unsolicited BFD cannot be in
passive role if it has a local client registered? But what I wonder is how
these transitions affect the operation. What happens if both BFD systems
are passive after changes in the clients registered? Or both are active?
- Section 5.1 appears to only RECOMMEND setting TTL to 255 while RFC
5881 says that TTL MUST be set to 255. What could be the case for not
setting TTL to 255?
- Nits:
- s/"Discriminator"/"My Discriminator"
- s/does not initiates/does not initiate/
- s/"remote-discriminator"/"Your Discriminator"/
Regards,
Greg
On Tue, Aug 4, 2020 at 6:10 AM Jeffrey Haas <[email protected]> wrote:
> Working Group,
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
>
> With apologies to the authors of BFD unsolicited, this document is past due
> for Working Group Last Call. The primary holdup on the document had been
> last minute interaction with the RFC Editor with regard to its impact on
> the
> BFD Yang model. That work had completed some time ago. (The Yang model,
> however, is still lingering in MISREF state.)
>
> This begins a last call period ending on 16 August.
>
> Please send your comments to the mailing list whether you think this work
> is
> ready to advance to the IESG or not.
>
> -- Jeff & Reshad
>
>
