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

[Greg Mirsky <[e-mail]>]

Thank you for catching that! Fixed.

Regards,
Greg

On Tue, Apr 16, 2024 at 3:16 PM Joe Clarke (jclarke) <[e-mail]>
wrote:

> 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]> 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]>
> 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
>
>