Hi Jeff, thank you for the expedient response. Please find my follow-up notes below tagged GIM2>>.
Regards, Greg On Thu, Dec 12, 2024 at 11:55 AM Jeffrey Haas <jh...@pfrc.org> wrote: > 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> 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. > GIM2>> As I understand, draft-ietf-bfd-unaffiliated-echo is applicable only in an environment in which the sender and reflector of an Unaffiliated Echo message are one IP hop away from each other. However, that is not guaranteed to be the case in SR-MPLS (and in MPLS in general) because the reflector of the Unaffiliated Echo may be several IP hops away. As a result, TTL check on the sender of the Unaffiliated Echo message will fail. For that reason, draft-ietf-bfd-unaffiliated-echo is outside the scope of draft-ietf-spring-bfd. It seems that it could be confusing to a reader if we reference any part of a document positioned as out of the scope. Besides, draft-ietf-bfd-unaffiliated-echo, if I understand it correctly, does not define the content of a BFD Echo message for scenarios that conform to RFC 5880, i.e., that use three-way handshake and allow transmission of BFD Echo message only if the session is in Up state. Am I missing something here? > > > 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. > GIM2>> Thank you. > > -- Jeff > >
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
