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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you for catching that! Fixed.

Regards,
Greg

On Tue, Apr 16, 2024 at 3:16 PM Joe Clarke (jclarke) <jclarke@xxxxxxxxx> wrote:

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

 

Joe

 

From: Greg Mirsky <gregimirsky@xxxxxxxxx>
Date: Tuesday, April 16, 2024 at 06:01
To: Joe Clarke (jclarke) <jclarke@xxxxxxxxx>
Cc: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>, draft-ietf-mpls-bfd-directed.all@xxxxxxxx <draft-ietf-mpls-bfd-directed.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, mpls@xxxxxxxx <mpls@xxxxxxxx>
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

 

Thank you for your help in improving the draft.

 

Regards,

Greg

 

On Mon, Apr 15, 2024 at 4:02PM Greg Mirsky <gregimirsky@xxxxxxxxx> 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:48PM Joe Clarke (jclarke) <jclarke@xxxxxxxxx> 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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux