# BFD IETF 110 - Thursday March 11th 2021 - 14:30-15:30 (UTC)
Chairs: Jeffrey Haas, Reshad Rahman
## Chairs update:
10 mins - Jeff Haas & Reshad Rahman
Acee: Take out BFD MPLS TE from BFD YANG and have another document for the MPLS
TE part. This is holding up OSPF/ISIS/PIM YANG.
Greg Mirsky: draft-ietf-mvpn-bess-failover is currently in RFC editor queue
Jeff Haas: Holdup point is IDR, need more generic mechanism?
Matthew Bocci: This was done in BESS because it is specific to VPNs.
Greg Mirsky: There are 2 other related documents. MPLS WG bfd-directed in path
engineering environments. Extends LSP-Ping for reverse direction. Would like
BFD community to take a look and share opinion on MPLS and BFD mailing lists.
Routing directorate review comments have been addressed, but reviewer believes
otherwise. Also: mpls-encpasulations-p2mp in MPLS WG (individual draft for
## BFD unsolicted (draft-ietf-bfd-unsolicited):
5 minutes - Reshad Rahman
Reshad Rahman: Need AD help to decide standards track v/s informational. Jeff:
No BFD protocol changes but changing the BFD YANG tree. John Scudder: We will
take it offline.
## BFD secure sequence numbers (draft-ietf-bfd-secure-sequence-numbers):
10 minutes - Mahesh Jethanandani
Mahesh Jethanandani: Shepherd suggested proposing algorithms for interop. What
happens when these algos become obsoleted/deprecated? Reshad Rahman: do as
usual, let implementors decide? John Scudder: Isn't algorithm local matter?
Mahesh Jethanandani: Both ends have to use the same algorithm Jeff Haas: Wasn't
there an algorithm suggested by security expert (Alan DeKok)? Mahesh
Jethanandani: I will look into it Jeff Haas: We don't want to use expensive
cyphers otherwise we are not optimizing authentication Acee Lindem: what about
wraps? Mahesh Jethanandani: taking monotonically seq number, generate cypher
from that Acee Lindem: ok
## BFD stablity (draft-ietf-bfd-stability):
5 minutes - Mahesh Jethanandani
Mahesh Jethanandani: Albert Fu suggested use of counters to track loss. BFD
YANG model was augmented to add the counter. IANA considerations section
updated and YD review requested by Reshad. Reshad Rahman: Are the counters
under a feature? Mahesh Jethanandani: No, it's the only thing in the module.
Jeff Haas: How do you know it's supported? Won't it be published as part of
NETCONF Hello/YANG library. Reshad/Mahesh: If you do not plan to support it,
you would not advertise it in the Hello and it would not be in YANG library.
## BFD unaffiliated echo (draft-ietf-bfd-unaffiliated-echo):
10 minutes - Weiqiang Cheng
Weiqiang Cheng: Gave description of updates to RFC5880 and the detailed
procedures. Greg Mirsky: For the 5880 updates, I have a concern about security
consideration. 5880 allows a device to regulate how frequently it can receive
BFD echo (or even deny them). Concern that a device might send too many BFD
echo packets. Weiqiang Cheng: We should add a note about this. Greg Mirsky:
Fields have to be initialized by sender e.g. set status to Up. That is not
described in the slides. Weiqiang Cheng: It is not mentioned in the slides but
it is mentioned in the document. Acee Lindem: Please don't use "Yang":
s/Yang/YANG Mach Chen: Responding to Greg's comments. It is transparent to the
remote system. The remote system treats this as a regular packet Jeff Haas: In
5880, we have signaling for echo support to express willingness to do so. In
the BBF use-case, there's no BFD state at the other end, so we can't use the
same procedure. Weiqiang Cheng: There is a risk that other end will do
something unexpected on BFD echo. Jeff Haas: This is called reflection attack
and should be mentioned in security considerations Greg Mirsky: BBF believes
their document (TR-146) lacks details, and would be happy if BFD WG "cleans
this up" Jeff Haas: In this document, we are allowed to be in Down state
without transmitting packets, that's an update to 5880 Greg Mirsky: BFD echo
format undefined in 5880. Does that mean all BFD echo must use this format?
Reshad Rahman: Clarify that this is just for BFD unaffiliated. Jeff Haas: Not
sure whether we have to specify contents of BFD echo. If you do, can you make
it an option? Weiqiang Cheng: We will come up with a proposal
## Actions for after IETF:
- Decide what to do with BFD YANG (split?)
- Status for unsolicited BFD (informational vs standards track)
- Push 3 authentications docs to IESG (close to being done in WG)
- New rev for BFD large packets
- New rev for BFD unsolicited
- New rev for BFD unaffiliated