Hi Les, I agree with your point of view except this statement:
> the consumer now needs to connect to every router in each IGP area (or at least each router of interest) Use of Producer's proxy can vastly simplify this if we ever get to that point. But yes IMP is just trying to relax BGP from carrying BGP-LS. The only exception in the current version of the spec is to optionally share local configuration - which I thought would be helpful. But I am not attached to it :) To your point on network management do you think BMP is a network management protocol ? It reports local RIBs, it reports peer state etc ... I think there is no clear line here what is and what is not a network mgmt. And depending who you ask you will get a different answer. Maybe this is why network management is in such a great shape today :) Many thx, Robert On Tue, Jul 12, 2022 at 4:03 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > 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
