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 <hayabusa...@gmail.com> 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 <gregimir...@gmail.com> 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= >> 40cisco....@dmarc.ietf.org> 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 <tony1ath...@gmail.com> *On Behalf Of *Tony Li >>> *Sent:* Monday, January 10, 2022 4:43 PM >>> *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> >>> *Cc:* Christian Hopps <cho...@chopps.org>; Peter Psenak (ppsenak) < >>> ppse...@cisco.com>; Robert Raszuk <rob...@raszuk.net>; Shraddha Hegde < >>> shrad...@juniper.net>; Aijun Wang <wangai...@tsinghua.org.cn>; Hannes >>> Gredler <han...@gredler.at>; lsr <lsr@ietf.org> >>> *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 >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >>> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
