Hey Hannes, Nice to hear from you !
Yes I was around when this "thing" happened :) Spoke with Stefano a lot about it ... And as you can see from my proposal I do value a lot of usability for existing controllers and I do support unification of exported data into common format. That is why DATA type 1 and 2 use BGP-LS TLVs as is. Btw this independent attempt by two WG groups to normalize link state data is a clear proof that the YANG model has failed here. > As the IMP proposal stands today there is not much additional value > compared to the local-LSDB that BGP-LS provides already. The advantage is that it does not need to touch BGP. Does not need to make an avalanche of drafts asking for extensions in IDR WG. See you know the BGP-LS started very innocently .. Let's ship over BGP session some topology and TE info for ALTO. But now it is growing out of propositions. And no matter if the info is useful or not we see drafts of people to just put their name on BGP RFC. And if it approved in LSR WG, SPRING, DETNET ... the gate is wide open. Do you think this makes sense ? > 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 ? Now as far as your comment about RIB data - that deserves a separate draft. On the other hand peer's state I already had in the draft - but decided to remove it for simplicity. Especially knowing that that peer state will be reflected in LSDB anyway. Also most of the info you listed is already available via telemetry. So I am not trying to duplicate this on purpose. However as I said if anyone finds it useful I will copy and paste it back to the draft. Kind regards, Robert On Tue, Jul 12, 2022 at 3:23 PM Hannes Gredler <han...@gredler.at> wrote: > 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 > | Lsr@ietf.org > | https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
