Re: [OPSAWG] IETF 109 - OPSAWG presentation https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00

[[e-mail]]

Hi Shuanglong and Rob,

First of all thank you very much for this question. I think they are very valid and good, but also occurring quiet often. I like share my view in OPSAWG. Regarding BMP, please involve the GROW working group as well.

The problem space you are describing is addressed in BMP with route mirroring and route monitoring. Before I come to this, let me give some background.

The aim of BMP is to encapsulate the control-plane PDU's and add control-plane device dimensions (peering, RIB and route-policy). Same as IPFIX does for forwarding-plane, adding forwarding-plane device (IE89 ForwardingStatus, IE10 IngressInterface, IE15 ipNextHopIPv4Address) and control-plane (IE18 bgpNextHopIPv4Address, IE46 mplsTopLabelType) dimensions. Without being able to establish context among control-plane, forwarding-plane and device,  the collected data has low value. We need to answer, Why? How? What?

draft-gray-sampled-streaming-03 caught my attention because it mirrors the data-plane, but disappointed not including device and control-plane dimensions for data-correlation. I am looking forward though how it develops. Keep in mind that IPFIX has already such described capabilities. For example RFC 7133.

In order to correlate among these three perspectives, control-plane, forwarding-plane and device, and overlap of key dimensions is needed. There YANG comes into picture. The strengths of YANG is the data modelling. Being able to combine configuration and operational metrics into one tree. Obviously, YANG was not intended to encapsulate control-plane PDU's nor data-plane frames. BMP and IPFIX will never including configurational metrics, but should provide sufficient dimensions to lookup a YANG tree and find the responsible configuration. Speaking as a co-author, what’s why the TLV work for BMP (draft-ietf-grow-bmp-tlv, draft-cppy-grow-bmp-path-marking-tlv, draft-xu-grow-bmp-route-policy-attr-trace)  is important.

YANG's aim is also not intended to be most efficient which is important in control-plane no causing any undesired side effects. BMP is part of the BGP process. It basically just mirrors PDU's, adding dimensions as lightweight it is possible. The aim of BMP route mirroring is to mirror PDU's. Where route-monitoring adding the RIB context. For instance if an update PDU is received but does not lead into a change into the RIB, than route-monitoring would not generate metrics where route-mirroring does. And isn't it that what your two use cases exactly describing? Please ask yourself when reading again your use case description if is important to have IS-IS control-plane and device dimensions being added to the PDU's or not. Do you want to know over which adjacency in which IS-IS process you learned that PDU and how it was added into the LSDB? If that resonates with you, consider BMP extending to other routing protocols as a valid approach.

Speaking for a network operator, by enabling BGP link-state and redistributing IS-IS and mirroring with BMP, we are currently doing exactly that. Retrieving the metrics directly from IS-IS would be a big plus. YANG push data-collection still has steps ahead to allow similar scale in data-collection than IPFIX already allows and being bullet proven. Speaking as a co-author, that’s why we are working on draft-ietf-netconf-udp-notif and draft-ietf-netconf-distributed-notif to enable lightweight data exposure directly from line cards without impacting route-processors and without re-inventing  the wheel by following the footsteps of IPFIX. Route-processors should stay focused on control-plane and expoes its own metrics.

Best wishes
Thomas

From: OPSAWG <[e-mail]> On Behalf Of Chenshuanglong
Sent: Thursday, January 7, 2021 2:46 AM
To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [OPSAWG] IETF 109 - OPSAWG presentation https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00

Hi Rob,
Thank you very much for your suggestions. I will also discuss this in the LSVR or RTGWG workgroup.
As you mentioned, the draft is about IS-IS PDUs. This is why I am not inclined to continue to expand based on YANG.
In addition, draft-gray-sampled-streaming-03 is an very interesting solution. I'll think about these solutions.

Best Regards
Shuanglong

From: Rob Wilton (rwilton) [mailto:[e-mail]]
Sent: Wednesday, January 6, 2021 5:37 PM
To: Chenshuanglong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Lizhenbin <[e-mail]<mailto:[e-mail]>>; Guyunan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: IETF 109 - OPSAWG presentation https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00

Hi Shuanglong,

[As a contributor]

I’m not that familiar with BMP and I’m not sure whether the BMP or routing experts are on the OPSAWG list.  If you have not already done so, then presenting this work in RTGWG and LSVR WGs may help see if there are more interested parties in those WGs, if you are not getting traction/interest within OPSAWG.

For me, I think the main question is what is the overlap between the information proposed by this draft to be exported via BMP extensions and what is already covered by the IS-IS YANG model (https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-42<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-isis-yang-isis-cfg-42&data=04%7C01%7CThomas.Graf%40swisscom.com%7Ce90c76f0cd594752bb5b08d8b2ae0321%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637455807745524865%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1%2BKo42FgBw6BguiQ1d0b2qqTsIuPOY4UelNrqXUrIHI%3D&reserved=0> – which is already in the RFC editor queue)?  If there is useful state information missing from the YANG model then it might be more effective to extend the IS-IS YANG model than provide an alternative mechanism to provide the same information.  I expect that the LSVR WG would probably be the best place to discuss this.

The one possible exception is the IS-IS PDUs.  It may be that extending BMP to be able to report those PDUs might be better than putting them in a YANG model (although interestingly, my understanding was that the OpenConfig approach was to expose the IS-IS PDUs via YANG, although that information might be out of date).  It would also be worth considering whether https://tools.ietf.org/html/draft-gray-sampled-streaming-03<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gray-sampled-streaming-03&data=04%7C01%7CThomas.Graf%40swisscom.com%7Ce90c76f0cd594752bb5b08d8b2ae0321%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637455807745534826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RYm9xKCLp7G9cqImwRgsc%2Buwmguhomz%2Bi21xZEF%2B1Mk%3D&reserved=0> could also be an effective solution for exporting ISIS PDUs for debugging/monitoring purposes, if that was within the remit of its filtering capabilities.

Regards,
Rob


From: Chenshuanglong <[e-mail]<mailto:[e-mail]>>
Sent: 06 January 2021 08:41
To: [e-mail]<mailto:[e-mail]>; Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
Cc: Lizhenbin <[e-mail]<mailto:[e-mail]>>; Guyunan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: IETF 109 - OPSAWG presentation https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gu-opsawg-network-monitoring-igp-00&data=04%7C01%7CThomas.Graf%40swisscom.com%7Ce90c76f0cd594752bb5b08d8b2ae0321%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637455807745534826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fcY5XWFTs3tEtJc1Xv87VbVFCMPYN1lbqaBSy5mqcug%3D&reserved=0>

hi all,

I presented network-monitoring-igp draft at IETF 109, see attached.  https://tools.ietf.org/html/draft-gu-opsawg-network-monitoring-igp-00<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gu-opsawg-network-monitoring-igp-00&data=04%7C01%7CThomas.Graf%40swisscom.com%7Ce90c76f0cd594752bb5b08d8b2ae0321%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637455807745544779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WbvZmWQQRmPy%2Fw240YrQwUGeYGGyOE%2FzWTICV8pR4Ik%3D&reserved=0>
We suggest to use BMP to monitor IGPs to avoid setting too many monitoring protocols for different control plane protocols.
In addition, it describes the requirements for collecting IGP information, such as the use cases listed in the draft.

Use Case1：IS-IS Route Flapping
   The IS-IS Route Flapping refers to the situation that one or more routes appear and then disappear in the routing table repeatedly.
   Route flapping usually comes with massive PDUs interactions (e.g., LSP, LSP purge...), which consume excessive network bandwidth, and excessive CPU processing.
In addition, the impact is often network-wide.  The localizing of the flapping source and the identifying of root causes haven't been easy work due to various reasons.

Use Case2： IS-IS LSDB Synchronization Failure
   During the IS-IS flooding, sometimes the LSP synchronization failure happens.  The synchronization failure causes can be generally classified into three cases，(1) the LSP is not correctly advertised， (2) LSP transmission error, (3) the LSP is received but not correctly processed.

What do you think of these use cases and extended BMP protocols?

Kind Regards
Shuanglong Chen