Re: Can Multihop BFD be protected using RLFA backup?

[Muthu Arul Mozhi Perumal <[e-mail]>]

Thank you Stephane, Sasha, Jeff and Nagendra, for your feedback!

Regards,
Muthu

On Fri, Jan 18, 2019 at 1:52 PM <[e-mail]> wrote:

> Hi,
>
>
>
> When you are using multihop BFD RFC5883 you are not monitoring an LSP.
> When IPFRR is activated, the primary goal of your BFD probe does not change
> and is still not to monitor an LSP but the remote IP destination. So it
> makes sense that FRR just pushes it stack without changing anything in the
> BFD encaps.
>
> In addition, I don’t think that it will be easy from a dataplane point of
> view to change the BFD encaps on the fly during FRR.
>
>
>
> Brgds,
>
>
>
> *From:* Muthu Arul Mozhi Perumal [mailto:[e-mail]]
> *Sent:* Thursday, January 17, 2019 12:02
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* [e-mail]
> *Subject:* Re: Can Multihop BFD be protected using RLFA backup?
>
>
>
> Hi Stephane,
>
>
>
> Thanks for your response. Please see inline..
>
>
>
> On Thu, Jan 17, 2019 at 3:27 PM <[e-mail]> wrote:
>
> Hi,
>
>
>
> I think that the fact that “control” packets can benefit of FRR is really
> implementation dependent. It is also linked to the place where BFD packets
> are created (RP or LC).
>
> From a theoretical point of view, nothing prevents FRR to be used as for
> any packet generated by the router itself.
>
>
>
> Do we know of any implementation that provides RLFA FRR protection to
> multihop BFD packets?
>
>
>
> Regarding the encapsulation, if your BFD client is using RFC5883, this
> will not change during FRR, the FRR will just push labels on top
> independently.
>
>
>
> The primary reason for my question on encapsulations is because RFC 4379
> has the foll. as one of the reasons for using the destination address
> in 127/8 range for IPv4 (0:0:0:0:0:FFFF:7F00/104 range for IPv6) for
> diagnostic packets sent over MPLS LSP:
>
>    1. Although the LSP in question may be broken in unknown ways, the
>
>       likelihood of a diagnostic packet being delivered to a user of an
>
>       MPLS service MUST be held to an absolute minimum.
>
>
>
> Since multihop BFD uses a routable destination address, wondering whether
> there would be any issues if multihop BFD packets are sent over the RLFA
> backup path without following RFC 5884 encapsulation..
>
>
>
> Regards,
>
> Muthu
>
>
>
> Again, the possibility to get FRR is really implementation dependent, as
> the forwarding decision of the BFD packet may not be taken by the network
> processor of the LC.
>
>
>
> Brgds,
>
>
>
> *From:* Rtg-bfd [mailto:[e-mail]] *On Behalf Of *Muthu
> Arul Mozhi Perumal
> *Sent:* Thursday, January 17, 2019 10:16
> *To:* [e-mail]
> *Subject:* Can Multihop BFD be protected using RLFA backup?
>
>
>
> Hi All,
>
>
>
> Multihop BFD (RFC 5883) packets are sent over UDP/IP. The encapsulation
> used is identical to single hop BFD (RFC 5881) except that the UDP
> destination port is set to 4784.
>
>
>
> Now, suppose on the ingress node there is no IP/LFA backup path for the
> destination address tracked by multihop BFD, but there exists an an RLFA
> backup path to that destination. In this case, is multihop BFD expected to
> be protected using the RLFA backup path i.e should multihop BFD packets be
> sent over the RLFA backup path if the primary path goes down?
>
>
>
> If multihop BFD packets are to be sent over the RLFA backup path, what
> encapsulation should the ingress use? The encapsulation specified in RFC
> 5883 or the encapsulation specified in RFC 5884 (MPLS BFD)?
>
>
>
> Please let me know you opinion.
>
>
>
> Regards,
>
> Muthu
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>