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]

 



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