Greg,
> On Dec 12, 2024, at 2:51 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > > On Thu, Dec 12, 2024 at 6:31 AM Jeffrey Haas <jh...@pfrc.org > <mailto:jh...@pfrc.org>> wrote: > In section 6, discussing BFD Echo (not Echo BFD), the text states: > > "A BFD Control packet MAY be used as the payload of Echo BFD." > > BFD Unaffiliated Echo[1] has recently been sent to the IESG. The work in > that draft covers the details for BFD to "talk to itself". I'd suggest > leveraging this as a reference in the spring document. > GIM>> Would the following update be acceptable to you: > OLD TEXT: > The use of other types of Echo BFD payload is outside the > scope of this document. > NEW TEXT: > The use of Echo BFD function in modes other than defined in > [RFC5880], e.g., [I-D.ietf-bfd-unaffiliated-echo], and other types of > Echo BFD payload are outside the scope of this document. I think additionally what is needed is to delete the other text about what is intended to be inside such echo packets. The reference to bfd-unaffiliated covers those procedures and they've had the review of the BFD WG. > > Note that the binding SID specific text is still appropriate in the spring > document. > GIM>> Do you see any additional specific uses of a Binding SID for BFD over > SR-MPLS beyond the BFD Echo function? I'm not a strong student of building SR networks. In general, I'd think creating a binding SID specific to BFD probably is a bit contrary to the desired role of this extension to validate the end to end forwarding path(s) for a set of SIDs. But similar to many of the other tradeoffs we tend to do practically for BFD, if it simplifies the procedures and the operator and implementing vendor are satisfied that you're providing validation or protection to the tested endpoint, all should be good. -- Jeff
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
