Hannes - Thanx for the perspective. Your post reminds me of something I wanted to say.
This discussion was started to discuss alternatives to BGP-LS. It has quickly broadened to include discussion of what I would call network management. This is fine - if the community wants to look at both use cases I have no objection. But I think it is important to understand the difference in requirements. The consumer of BGP-LS needs to acquire the topology information for multiple IGP areas/domains. To get this, the consumer only needs to connect to a small number of ABRs/IGP area. And currently there is only one standardized way to do this (RFC 7752). However, once we start talking about information which is NOT part of the LSDB (e.g., adjacencies, rib contents) the consumer now needs to connect to every router in each IGP area (or at least each router of interest) and the existing alternatives to support this are a different set (BMP, YANG data models, telemetry). This does not preclude the use of a single "protocol" (such as IMP) to support both use cases, but since the requirements are very different I would find it easier to have a meaningful discussion if the two use cases were discussed in separate threads. As it seems likely we are headed towards an interim meeting on such topics (based on available time and the WG chair comments) I would also like to know if both topics are in scope for a common meeting or if they will be split into separate meetings. Either way is fine w me. Thanx. Les > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Hannes Gredler > Sent: Tuesday, July 12, 2022 6:23 AM > To: Robert Raszuk <[email protected]> > Cc: [email protected]; lsr <[email protected]>; idr@ietf. org > <[email protected]>; Susan Hares <[email protected]> > Subject: Re: [Lsr] IGP Monitoring Protocol > > Hi Robert, > > When designing BGP-LS we had to make a fundamental choice for expressing > an link-state graph. > the two models under consideration: > > 1) encapsulating raw IGP LS PDUs into some NLRI > 2) transcoding all elements of a graph (nodes, links, prefixes, node > attributes > and link attributes) > into some NLRI > > We did see some value for getting visibility of serialized LS PDUs (proposal > 1), > but then decided > against it as the primary use-case has been to be friendly to controllers > where controller developers > told us they do not want to to implement each and every protocol specific > IGP extension, but rather be comfortable > with a "protocol neutral" representation of a LS graph (proposal 2). > So here we are - if a certain feature is relevant to a controller, then you > need > to specify a > BGP-LS transcoding scheme / TLV - no way around that if you want to be > friendly to controller developers. > As the IMP proposal stands today there is not much additional value > compared to the local-LSDB that BGP-LS provides already. > > However, for debugging IGPs there is certainly some value in monitoring the > flooding subsystem. > Now if you want to however monitor what's going on at the flooding level of > your IGP then there is > a tad of information missing in the current proposal. > > For further illustration let me pull-up the BMP analogy, where there is a > clear > per-RIB orientation: > e.g. from which peer a NLRI has been received from ? > what NLRI has been sent to particular peer ? > per-peer stats, global stats ? > > That per-adj related information is IMO missing for IMP to be useful. > additional data of interest -> where (interface) and when a LS PDU has been > received (redundant copies ?), retransmisison stats, > differentiate between LSDB-in / LSDB-out, LSDB-self-originated ? > > I am sure that bruno and his team have way more ideas for data that they > would be interested in ;-) > > /hannes > > On Fri, Jul 08, 2022 at 09:20:04PM +0200, Robert Raszuk wrote: > | Dear LSR WG, > | Based on ongoing discussion in respect to the future of BGP-LS I > | committed myself to put together an alternate proposal. > | The main goal is not to just publish a -00 version of the draft using > | different encapsulation. The goal is to make a useful tool which can help > | to export link state information from network elements as well as assist > | in network observability. > | The IGP Monitoring Protocol (IMP) draft has been posted and should be > | available at: > | https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/ > | One of the key points I wanted to accomplish was full backwards > | compatibility with TLVs defined for BGP-LS. In parallel other formats > | (optional) are also supported. > | The PUB-SUB nature or FILTERING capabilities are in the spec however > as > | noted in the deployment section there is no expectation that this should > | be supported directly on routers. Concept of Producer's Proxies has been > | introduced to support this added functionality as well as provide fan-out > | (analogy to BGP route reflectors). > | I encourage everyone interested to take a look and provide comments. > At > | this point this document is nothing more than my individual submission. > | Offline I have had few conversations with both operators and vendors > | expressing some level of interest in this work. How we proceed further > (if > | at all :) depends on WG feedback. > | Kind regards, > | Robert. > | PS, I do believe this work belongs in LSR WG pretty squerly. > > | _______________________________________________ > | Lsr mailing list > | [email protected] > | https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
