Thank you Stephane, Sasha, Jeff and Nagendra, for your feedback! Regards, Muthu
On Fri, Jan 18, 2019 at 1:52 PM <[email protected]> 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:[email protected]] > *Sent:* Thursday, January 17, 2019 12:02 > *To:* LITKOWSKI Stephane OBS/OINIS > *Cc:* [email protected] > *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 <[email protected]> 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:[email protected]] *On Behalf Of *Muthu > Arul Mozhi Perumal > *Sent:* Thursday, January 17, 2019 10:16 > *To:* [email protected] > *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. > >
