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. 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. 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. 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. 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. 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. 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. 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 Best wishes Thomas From: GROW <[email protected]> On Behalf Of Robert Raszuk Sent: Saturday, July 9, 2022 9:49 PM To: Jeff Tantsura <[email protected]> Cc: lsr <[email protected]>; [email protected] [email protected] <[email protected]>; idr@ietf. org <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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) <[email protected]<mailto:[email protected]>> wrote: Hi Robert, From: Robert Raszuk <[email protected]<mailto:[email protected]>> Date: Friday, July 8, 2022 at 4:36 PM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: lsr <[email protected]<mailto:[email protected]>>, IDR List <[email protected]<mailto:[email protected]>>, Susan Hares <[email protected]<mailto:[email protected]>> 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) <[email protected]<mailto:[email protected]>> wrote: Speaking as WG chair: From: Lsr <[email protected]<mailto:[email protected]>> on behalf of Robert Raszuk <[email protected]<mailto:[email protected]>> Date: Friday, July 8, 2022 at 3:21 PM To: lsr <[email protected]<mailto:[email protected]>> Cc: IDR List <[email protected]<mailto:[email protected]>>, Susan Hares <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> 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>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
