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
