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*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
