Hi Greg Thanks for the reference.
Agreed on the different UDP port 3784 and 4784 to differentiate the single hop and multi hop sessions respectively. In the multi hop BFD scenario to monitor the egress PE loopbacks in the case where an RR exists and all PEs are Route-Reflector Clients, the BFD multi hop BFD session would monitor PE to RR iBGP peering underlay path, however how would an ingress PE monitor the liveliness of egress PE. Also as best practice is to keep the RR out of the forwarding plane not in-line - off to the side a as the RR is meant to handle control plane only and not data plane traffic as it maybe on a different lower end platform type then the P and PE nodes such as a NFV VNF VM virtualized box. So it would be difficult for the multi hop BFD PE to RR to be able to monitor the PE to PE LSP forwarding plane failure path. Kind Regards Gyan On Mon, Jan 10, 2022 at 8:50 PM Greg Mirsky <[email protected]> wrote: > Hi Gyan, > thank you for sharing the operator's perspective and experience on using > the multi-hop BFD. Thinking of additional challenges, I may add the > authentication of BFD Control packets. But the extra-processing can be > significantly reduced by draft-ietf-bfd-optimizing-authentication-13 - > Optimizing BFD Authentication > <https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/>. > As for using single- and multi-hop BFD sessions simultaneously, that should > not present any problem as each type uses a different assigned destination > UDP port number. > > Regards, > Greg > > On Mon, Jan 10, 2022 at 5:36 PM Gyan Mishra <[email protected]> wrote: > >> >> Greg >> >> I believe the scalability context for multi hop BFD is the operational >> complexity introduced with the number of sessions especially within very >> large domains with inordinate number of routers. Single hop BFD is more >> manageable and is predominately user by operators for underlay failure >> detection. Also in a case where single hop BFD by an operators for failure >> detection does that preclude the use of multi hop BFD as well and any >> caveats with using both simultaneously. >> >> Kind Regards >> >> Gyan >> >> On Mon, Jan 10, 2022 at 8:28 PM Greg Mirsky <[email protected]> >> wrote: >> >>> Hi Les, >>> do you see anything that requires further specification in addition to >>> RFC 5883? >>> >>> Regards >>> Greg >>> >>> On Mon, Jan 10, 2022, 17:14 Les Ginsberg (ginsberg) <ginsberg= >>> [email protected]> wrote: >>> >>>> Tony – >>>> >>>> >>>> >>>> I could be more specific regarding my opinion about various >>>> alternatives that have been mentioned (BFD, OAM, BGP, pub-sub) – but it >>>> doesn’t make sense to me to comment on proposals which have not actually >>>> been defined. >>>> >>>> If someone (not necessarily you) wants to write up any of these >>>> proposals then we (the WG/Routing Area) could have a meaningful discussion >>>> about such alternatives. >>>> >>>> >>>> >>>> In the meantime, we started with the IGPs because: >>>> >>>> >>>> >>>> a)IGPs have the raw reachability info – they don’t have to get it from >>>> some other entity >>>> >>>> b)IGPs have the reliable flooding mechanism >>>> >>>> >>>> >>>> Given that we want to address a real deployment issue in a timely >>>> manner, we want to move forward. >>>> >>>> >>>> >>>> We – meaning the WG/IETF – are tasked with defining practical solutions >>>> to real problems. It’s fine to object to a proposal – but that doesn’t get >>>> us to a solution. >>>> >>>> I am not saying that you specifically are responsible for defining an >>>> alternate solution – but if “we” are to progress then we either need to >>>> accept an IGP solution or define an alternative. >>>> >>>> >>>> >>>> Now, if you are saying the problem doesn’t need to be solved – then we >>>> just disagree. >>>> >>>> >>>> >>>> Les >>>> >>>> >>>> >>>> >>>> >>>> *From:* Tony Li <[email protected]> *On Behalf Of *Tony Li >>>> *Sent:* Monday, January 10, 2022 4:43 PM >>>> *To:* Les Ginsberg (ginsberg) <[email protected]> >>>> *Cc:* Christian Hopps <[email protected]>; Peter Psenak (ppsenak) < >>>> [email protected]>; Robert Raszuk <[email protected]>; Shraddha Hegde < >>>> [email protected]>; Aijun Wang <[email protected]>; Hannes >>>> Gredler <[email protected]>; lsr <[email protected]> >>>> *Subject:* Re: [Lsr] BGP vs PUA/PULSE >>>> >>>> >>>> >>>> >>>> >>>> Les, >>>> >>>> >>>> >>>> >>>> >>>> And if customers could do what he suggested then they would not have an >>>> issue. >>>> >>>> >>>> >>>> But there are deployments where what he suggested is not possible – >>>> largely I think because the set of “prefixes of interest” is in itself >>>> large. >>>> >>>> >>>> >>>> >>>> >>>> Well, the alleged customers have not come forward to explain the >>>> situation. I would welcome more specifics, even under NDA. It’s hard to >>>> relate to allegations of scale without specifics. If the area has that many >>>> PEs in it, then is really too large to be a single area in the first place? >>>> >>>> >>>> >>>> >>>> >>>> So while not all customers have an issue, some customers do and we are >>>> trying to find a way to address those deployments. >>>> >>>> >>>> >>>> As far as the alternative proposals, I will comment on them if/when >>>> there is something visible – but I think they will all suffer from scale >>>> issues. >>>> >>>> >>>> >>>> >>>> >>>> They have been proposed here and have not been refuted. >>>> >>>> >>>> >>>> Everything always suffers from scale issues, so that’s not exactly >>>> constructive. >>>> >>>> >>>> >>>> I would be more than happy to write up the pub-sub proposal, but … it’s >>>> not my customer and it’s not in my charter to contribute to your revenue. >>>> :) >>>> >>>> >>>> >>>> Tony >>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lsr >>>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *Email [email protected] <[email protected]>* >> >> >> >> *M 301 502-1347* >> >> -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
