Re: [mpls] Opsdir last call review of draft-ietf-mpls-bfd-directed-27

["Joe Clarke (jclarke)" <[e-mail]>]

Thanks, Greg.  Looks like you have a typo in the abstract, “BFD system rto equest”.

Joe

From: Greg Mirsky <[e-mail]>
Date: Tuesday, April 16, 2024 at 06:01
To: Joe Clarke (jclarke) <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Opsdir last call review of draft-ietf-mpls-bfd-directed-27
Hi Joe,
I've uploaded the new version that includes updates resulting from our discussion.
Name:     draft-ietf-mpls-bfd-directed
Revision: 28
Title:    Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs)
Date:     2024-04-16
Group:    mpls
Pages:    11
URL:      https://www.ietf.org/archive/id/draft-ietf-mpls-bfd-directed-28.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/
HTML:     https://www.ietf.org/archive/id/draft-ietf-mpls-bfd-directed-28.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-mpls-bfd-directed
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-bfd-directed-28

Thank you for your help in improving the draft.

Regards,
Greg

On Mon, Apr 15, 2024 at 4:02 PM Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Thank you, Joe, for your quick response. I'll upload the updated version with the updates addressing the TSVART review.

Regards,
Greg

On Mon, Apr 15, 2024 at 3:48 PM Joe Clarke (jclarke) <[e-mail]<mailto:[e-mail]>> wrote:
Thanks for the modifications.  They read well to me.  As to the question…

Finally, my question.  In the Operational Consideration, what would (or should)
happen to the underlying service while the LSP ping is processed in the case of
reverse-path FEC failure?  Is there guidance to provide to maintain service
while this new session might be established?
GIM>> That, in my opinion, is the formative question; thank you for that. It is assumed that the operator controls the network to which the Reverse PAth Control TLV is applied. If theat is the case, the failure of the installed reverse path is a case of the network failure. The operator, I assume that from the ingress BFD peer, is notified, and then can switch the reverse path of the BFD session. I imagine, that there could be other switchover policies, but I believe that it is essential that the ingress BFD peer detects the network failure if the reverse path of the BFD session fails. WDYT?

JMC: I read this differently the first time.  Thinking on your figure, I agree with you.  If the tunnel A-B-C-D-G-H is good, but the reverse H-G-D-C-B-A is not (and this is the reverse path requested), then we can assume there isn’t bidirectional forwarding and the ingress peer should be informed.  That likely should warrant a service interruption unless there is another viable failover path.

Joe