Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk <[e-mail]>]

Hello Thomas,

Many thx for your comments and review. See inline ..

On Sun, Jul 10, 2022 at 7:13 AM <[e-mail]> wrote:

> Dear Robert,
>
>
>
> I reviewed draft-raszuk-lsr-imp-00 and have some firsts comments and
> suggestions.
>
>
>
> First of all, speaking as a network operator who is using BMP to gain
> visibility into the BGP control-plane, seeing the real benefits in
> operation every day, I was looking very forward at IETF seeing a similar
> debugging kind of approach being applied to IGP. You addressed that aspect
> very well. Thank you very much.
>
>
>
> I would like to understand if data type 3-9 described in section 5
> exporting the initial LSDB state when the transport session is being
> established and once fully exported, only the subsequential updates?
> Comparable to route-monitoring in BMP.
>

Yes this is exactly the intention. I will make it more clear in the text.


> In section 5 you are describing data type 7, 8 and 9. Exporting LSDB as
> structured data in YANG. I like the idea in general but doubt that vendors
> will fancy implementations due to the additional I/O impact on the IGP
> process.
>

Well that addition was actually inspired by NOKIA claiming existing support
for it already. I had some discussions with Gunter off line on this.

Furthermore I think telemetry with YANG model is reality. Architecture wise
conversion to YANG does not need to happen in the IGP process itself. There
can be a standalone encoder process which takes feed from IGP process in
any internal format as prepared and packs it into YANG envelops. Many
modern vendors keep all protocol data in a database. The database can on
changes just push "raw" data to such YANG export engine.



> However I think it is very valuable to have the LSDB modelled in YANG for
> data correlation purposes. I suggest that the YANG modelling can happen on
> the producer with data type 7, 8 and 9 or on the receiver side by
> converting data type 3-6 and 10-13 into JSON/XML with the YANG data model.
>

Indeed - that very well can be the case if YANG model for IGPs will be up
to speed with all extensions. And I wanted to try to stay out of
specifying anything how Receiver(s) can consume and modify the data. The
only exception I made here was a statement that DATA Types 1 & 2 are 100%
compatible by design with today's BGP-LS SAFI 71 & 72.



> I suspect that the YANG model itself for modelling the LSDB itself is not
> part of the document, therefore a reference to existing drafts such as
> draft-ietf-ospf-yang would help to better understand that context.
>

Indeed. Will add it !


In section 5 you are describing in figure 2 the data message header. Here I
> suggest to add besides the "Router Identifier" also the "Process
> Identifier" to have the proper device context if more than one process is
> running.
>

Well This is exactly why I have Section 8 :) Do you think in the light of
that section we still need to carry process ID ?


> Lessons learned from BMP is that knowing the control-plane state alone
> isn't enough for proper data correlation for IPFIX Flow Aggregation as
> described in RFC 7015. We need also to understand how (active, passive,
> ecmp, not considered etc.) the path is being installed into the RIB. At BMP
> we are addressing this with draft-cppy-grow-bmp-path-marking-tlv. I
> suggest to include this RIB aspect into IMP from day 1. If that makes sense
> to you as well, I gladly make a proposal.
>

Very interesting comment !  I was thinking for a while if I should add
anything in respect to direct peer's state. I decided not to as part of
that is reflected in LSDB.

You are suggesting the RIB side. I agree on the importance of it but I
think we have two challenges:

A) The RIB interactions with local subsystems are almost always
proprietary. There is no standard there. So may be a bit hard to spec.

B) I think this is very important and to do it well perhaps a separate
document would be a better idea ? RIB Monitoring Protocol (RMP) ?

To your analogy with draft-cppy-grow-bmp-path-marking-tlv it is mainly
about best path selection criteria. Not sure if this is applicable to link
state protocols where protocol's local RIB is a product of SPF algo and
insertion to main RIB is subject to admin distance comparison.


> Regarding the subscription aspect described in section 3. Here I would
> prefer a similar approach as draft-cptb-grow-bmp-yang, being done through a
> NETCONF/RESTCONF configured subscription. A YANG model gives the
> possibility not only to define but also to monitor the subscription which
> is fundamental for proper data collection. draft-arokiarajseda-ipfix-data-export-yang-model
> does the same for IPFIX. For YANG push this is defined in RFC 8641.
>

Please observe that the PUB-SUB subscription only happens at the DATA
Types. That IMO is an IMP property. I agree that what specific elements are
sent can be done with the NETCONF/RESTCONF mechanism.

For now I refrained from adding this to the spec. Only added top level TLV
filters.

Said this I am very open to follow your above recommendation for YANG DATA
Types and need for more granular subscriptions. But I think I would rather
see this applicable to Producer's Proxies not Producers directly. Just
trying to keep Producers as light as possible as not all RP/RE can handle
too much of such load.


> Regarding the terminology of "Producer" and "Receiver". I suggest to align
> the wording with existing Network Telemetry (RFC 9232) protocols.
> Unfortunately they aren't aligned among at all even though they are doing
> more or less all the same. Exporting monitoring data to a data collection.
> My personal favorite is Exporting and Collecting Process.
>
>
>
> IPFIX:               Exporting Process, Collecting Process
>
> BMP:                 Management Station, Monitoring Station
>
> YANG push:       Publisher, Receiver
>
> IMP:                  Producer, Receiver
>

I used the Producer term as this is how some implementations call its
components. The receivers are Clients.

But if we think that "Publisher" term is a better fit I have no issue
renaming it such. Receiver could stay as is or could be called Client too.

Many thx and thank you again for your review and excellent comments.

Robert



>
>
> Best wishes
>
> Thomas
>
>
>
> *From:* GROW <[e-mail]> *On Behalf Of *Robert Raszuk
> *Sent:* Saturday, July 9, 2022 9:49 PM
> *To:* Jeff Tantsura <[e-mail]>
> *Cc:* lsr <[e-mail]>; [e-mail] [e-mail] <[e-mail]>;
> idr@ietf. org <[e-mail]>
> *Subject:* Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
>
>
>
> Thx Jeff !
>
>
>
> Also I welcome more reviews and suggestions for additions or deletions of
> parts of it. For now I tried to keep it very simple for routers -
> essentially setup new p2p TCP or QUIC sessions and send over exactly what
> you put in BGP today. In the same time I see use cases beyond that so added
> few optional more DATA Types.
>
>
>
> With basic DATA Types 1 or 2 there is zero changes needed on the receivers
> - some folks told me this is huge advantage.
>
>
>
> Then two optional messages REQUEST and FILTER provide ability for trimming
> excessive data either on the Producer or Producer's Proxy.
>
>
>
> Many thx,
>
> Robert
>
>
>
>
>
> On Sat, Jul 9, 2022 at 9:39 PM Jeff Tantsura <[e-mail]>
> wrote:
>
> Speaking as RTGWG chair:
>
>
>
> Robert - I don’t think we’d have enough time to accommodate a good
> discussion during IETF114 (we got only 1 slot), however would be happy to
> provide a platform for an interim.
>
> The topic is important and personally (being a very large BGP-LS user) I’d
> like to see it progressing.
>
> Cheers,
>
> Jeff
>
>
>
> On Jul 8, 2022, at 14:44, Robert Raszuk <[e-mail]> wrote:
>
> 
>
> Hi Acee,
>
>
>
> Yes, by all means input from the operator's community is needed. It can be
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
> We have already seen input from some operators and their opinion on adding
> and distributing more and more link state protocol and topology data in
> BGP. More such input is very welcome.
>
>
>
> And to your point about RFC9086 - I see nothing wrong in keeping BGP
> information in BGP. So IGP Monitoring Protocol does not target to shut down
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>
>
>
> Controllers which today listen to BGP-LS need a number of information
> sources and that spread will only keep increasing as more inputs are
> becoming necessary for its computations.
>
>
>
> Regards,
>
> Robert.
>
>
>
>
>
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee) <[e-mail]> wrote:
>
> Hi Robert,
>
>
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Friday, July 8, 2022 at 4:36 PM
> *To: *Acee Lindem <[e-mail]>
> *Cc: *lsr <[e-mail]>, IDR List <[e-mail]>, Susan Hares <
> [e-mail]>
> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>
>
>
> Hi Acee,
>
>
>
> Thank you. I was not planning to present it in the upcoming IETF.
>
>
>
> > Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.
>
>
>
> An alternative approach could be to see how many stakeholders do not want
> to further (for no good reason) to trash BGP. That to me would be in this
> specific case a much better gauge.
>
>
>
> In that case, it seems to me that this discussion should be relegated to
> IDR. Note that there is already non-IGP information transported in BGP-LS,
> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc9086%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7C5ab3e0eb45c041f362c808da61e426fc%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637929929779223085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JAytgVAYRCrfCPWpfAHJMLk5fH67aEFtoyCHbo8s0Ps%3D&reserved=0>).
> I implemented this on our data center routers (NXOS) years and it is solely
> BGP specific.
>
>
>
> Thanks,
>
> Acee
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee) <[e-mail]> wrote:
>
> Speaking as WG chair:
>
>
>
> *From: *Lsr <[e-mail]> on behalf of Robert Raszuk <
> [e-mail]>
> *Date: *Friday, July 8, 2022 at 3:21 PM
> *To: *lsr <[e-mail]>
> *Cc: *IDR List <[e-mail]>, Susan Hares <[e-mail]>
> *Subject: *[Lsr] IGP Monitoring Protocol
>
>
>
> 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/
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-raszuk-lsr-imp%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7C5ab3e0eb45c041f362c808da61e426fc%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637929929779223085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rju%2FzMhLKC2gbVjN8uk2CZqolzCxAmHazPuiqHKOpJQ%3D&reserved=0>
>
>
>
> 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.
>
>
>
> Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.  By stakeholders, I mean operators and vendors
> who are committed to implementing and deploying it - not simply those who
> you are able to enlist as co-authors. Note that our IETF 114 LSR agenda is
> full (with multiple agenda items not making the cut).
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7CThomas.Graf%40swisscom.com%7C5ab3e0eb45c041f362c808da61e426fc%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637929929779223085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2Zr2Do3M4%2FKuXYgHuaA6Q5vAqfZAiB9DyemclasStEc%3D&reserved=0>
>
>