Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf

[Haoyu song <[e-mail]>]

Hi Thomas,

Thank you very much for your support! I'm glad to see that the vision of the draft is well aligned with yours.
You pointed out a very important issue (metrics correlation) that definitely needs to be addressed by IETF. We'll articulate this based on your comments.
Schema conversion is also a real issue and solid requirement. My only concern is if this is in the working scope of IETF. Maybe for the completeness of the work, we should also mention it at least. Or we should think about how to make the conversion easier.

We are looking forward to your further help  and contribution!

Best regards,
Haoyu

From: OPSAWG [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Sunday, March 17, 2019 3:09 AM
To: Tianran Zhou <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf


Hi Tianran and co-authors,



I support the adoption from a network operator perspective. Thank you very much that you driving this important topic at IETF.



I agree with the authors that IETF needs to ensure that all activities covered by Network Telemetry has to be coordinated to allow metric correlation and Big Data integration to gain visibility into our networks. Without visibility into our networks, networks and automation won't reach maturity levels we know from other industries..



I like to add the following input:



Section 3, "The Necessity of a Network Telemetry Framework", paragraph "Network visibility presents multiple viewpoints"

--

In section 4.2 "Data Objects" you lay out nicely the 3 different areas metrics can be collected. Control-Plane, Forwarding-Plane and Management (device, physical topology). It is important to describe that if metrics are correlated between these 3 areas, metrics can be viewed from these 3 different viewpoints. Examples:



Traffic Impact:                                                From forwarding-plane perspective we can verify if traffic impact was caused due to a control-plane or a management plane change or not.

Service Provisioning:                                    From a control-plane perspective we can verify if service provisioning was successful and undesired traffic or device impact was caused.

Physical Topology Modification:               From a device/physical topology perspective, we can verify when new devices are introduced or existing are changed or upgraded, if control-plane worked, forwarding path was adjusted to redundant device and no traffic impact is visible from a customer/service perspective.



For a automated closed loop operation this is essential. Same as an autopilot in an modern airplane works, it needs sensors covering multiple aspects. When change is performed, it has to verify if desired outcome is achieved.



These metric correlation between control-plane, forwarding-plane and management (device, physical topology) can only be achieved when:



1.           Each area has key fields which contain the same values

2.           These time series metrics have same timestamps



In those areas, IETF and this NTF draft needs to play an important role by not only point out which key metrics exists (find the right amount is key), it also has to ensure that within RFC's covering metric collection, enrichment and correlation, this aspects are fostered.



Example1: With "if-index" field in ietf-interfaces.yang  model (A YANG Data Model for Interface Management, RFC 7223) we are able to correlate to IPFIX (RFC 7011) entity 10 (ingressInterface) and 14 (egressInterface).

Example2: With "ip address" field in ietf-ip.yang model (A YANG Data Model for IP Management, RFC 8344) we are able to correlate BGP next-hop attribute in BMP (BGP Monitoring Protocol, RFC 7854).

Example3: With IPFIX entity 90 (mplsVpnRouteDistinguisher) we are able to correlate to BGP route-distinguisher in BMP (BGP Monitoring Protocol, RFC 7854).



If you look at the last example and the following IETF draft which wants to enrich forwarding-plane with BGP metrics on the flow exporter, we have to ask ourselves if IPFIX entity 90 is a key field and should be part of any RFC which correlates between BGP control-plane and forwarding-plane.



Export BGP community information in IP Flow Information Export (IPFIX)

https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-12



Another aspect which is currently not covered is schema conversion.. Network metrics have schema definitions (YANG, IPFIX template, BMP message format) which are currently not supported in Big Data environment. Widely used in Hadoop environments is AVRO (https://en.wikipedia.org/wiki/Apache_Avro). We need to describe and allow that schema conversion is possible.



[cid:image002.jpg@01D4DD77.649C7950]





Further, IETF should take the step towards Big Data and standardize a schema language which can be used at Big Data and network metric schema's can be easily converted to. Without proper schema conversion, collected metrics can't be automatically processed at scale within Big Data environments.



Kind regards

Thomas Graf

____________________________________________________________________________

Network Engineer

Datacenter Functions

Telefon [phone]

Mobile  [phone]

[e-mail]<mailto:[e-mail]>

____________________________________________________________________________

Swisscom (Schweiz) AG

IT, Network & Infrastructure

Datacenter Functions

Binzring 17

8045 Zürich

www.swisscom.com<http://www.swisscom.com>

Postadresse:

Binzring 17

8045 Zürich





-----Original Message-----
From: OPSAWG <[e-mail]<mailto:[e-mail]>> On Behalf Of Tianran Zhou
Sent: Monday, March 11, 2019 3:40 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf



Hi WG,



As you may have seen, the authors have posted an update to draft-song-opsawg-ntf-03 to address discussions in Bangkok and after.

https://datatracker.ietf.org/doc/draft-song-opsawg-ntf/

https://mailarchive.ietf.org/arch/msg/opsawg/g338UPfVAtOhVhdDzhJcR2nS76E



In Bangkok there seemed to some interest in working on this topic and the chairs believe it is in scope for this working group.



This email starts a poll for adoption.

If you support adopting this document please say so, and please give an indication of why you think it is important. Also please say if you will be willing to review and help the draft.

If you do not support adopting this document as a starting point for work on this topic, please say why.

This poll will run until 9am in Prague on Monday 25th March.



Regards,

Tianran, OPSAWG Co-Chair



_______________________________________________

OPSAWG mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/opsawg