Added extension ID to be used for exporting Juniper telemetry header.

[amanand]

The extension ID will be used to export the telemetry header used by Juniper for exporting key information for debugging as well as for use by collectors. Details about the message that is exported is present here:
https://github.com/Juniper/telemetry/blob/master/20.1/20.1R1/protos/GnmiJuniperTelemetryHeader.proto

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[amanand]

@googlebot I signed it Thanks, Amish From: googlebot <[email protected]> Reply-To: openconfig/gnmi <[email protected]> Date: Tuesday, May 26, 2020 at 9:26 PM To: openconfig/gnmi <[email protected]> Cc: Amish Anand <[email protected]>, Author <[email protected]> Subject: Re: [openconfig/gnmi] Added extension ID to be used for exporting Juniper telemetry header. (#76) [External Email. Be cautious of content] Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/<https://urldefense.com/v3/__https:/cla.developers.google.com/__;!!NEt6yMaO-gk!WiON_-OG9g-CO2orT6zAPVTlJLq8yBMFoxLLpi0n58OFafxPF0acNPKEFCVwzQo$> to sign. Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

…

________________________________ What to do if you already signed the CLA Individual signers * It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data<https://urldefense.com/v3/__https:/cla.developers.google.com/clas__;!!NEt6yMaO-gk!WiON_-OG9g-CO2orT6zAPVTlJLq8yBMFoxLLpi0n58OFafxPF0acNPKEYOcd1Pg$> and verify that your email is set on your git commits<https://help.github.com/articles/setting-your-email-in-git/>. Corporate signers * Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot<https://urldefense.com/v3/__http:/go/cla*troubleshoot__;Iw!!NEt6yMaO-gk!WiON_-OG9g-CO2orT6zAPVTlJLq8yBMFoxLLpi0n58OFafxPF0acNPKEDphHDe8$> (Public version<https://urldefense.com/v3/__https:/opensource.google/docs/cla/*troubleshoot__;Iw!!NEt6yMaO-gk!WiON_-OG9g-CO2orT6zAPVTlJLq8yBMFoxLLpi0n58OFafxPF0acNPKEg5L_SMA$>). * The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data<https://urldefense.com/v3/__https:/cla.developers.google.com/clas__;!!NEt6yMaO-gk!WiON_-OG9g-CO2orT6zAPVTlJLq8yBMFoxLLpi0n58OFafxPF0acNPKEYOcd1Pg$> and verify that your email is set on your git commits<https://help.github.com/articles/setting-your-email-in-git/>. * The email used to register you as an authorized contributor must also be attached to your GitHub account<https://github.com/settings/emails>. ℹ️ Googlers: Go here<https://urldefense.com/v3/__https:/goto.google.com/prinfo/https*3A*2F*2Fgithub.com*2Fopenconfig*2Fgnmi*2Fpull*2F76__;JSUlJSUlJQ!!NEt6yMaO-gk!WiON_-OG9g-CO2orT6zAPVTlJLq8yBMFoxLLpi0n58OFafxPF0acNPKEbxFGObI$> for more info. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#76 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACLX4NGQXRLUE3PBDJFW2X3RTSI6FANCNFSM4NLXYXGA>. Juniper Business Use Only

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[robshakir]

Apologies, I thought that I'd seen a review of this go by/done one myself.

There are a couple of fields that it would be good to have clarified in the proto that you linked. Particularly:

• event_timestamp -- this sounds like it should be the same as the timestamp in the Notification? In general, extensions should not create ambiguity between fields (since this hurts interoperability). Can you provide some clarification on this one?
• export_timestamp -- is there a reference that determines what the export timestamp means? It would be good to clarify that this is informational w.r.t an internal of your architecture, rather than duplicating the gNMI Notification's timestamp field.

Thanks for considering these changes/clarifications.

Cheers,
r.

[amanand]

Hi Rob, The timestamps in the extension proto are informational and useful in debugging any issues related to latency or KPI evaluation of the telemetry data. The event_timestamp indicates the time when the event occurs on the device whereas the Notification timestamp is when the device emits the data to the collector. The export_timestamp indicates the time when complete telemetry data corresponding to either event or periodic data is sent from the producer. Difference between export_timestamp and event_timestamp will indicate the total time taken to fire the event at producer. Difference between export_timestamp and the timestamp in Notification will indicate the internal latency in the infra. Thanks, Amish From: Rob Shakir <[email protected]> Reply-To: openconfig/gnmi <[email protected]> Date: Wednesday, June 17, 2020 at 3:58 PM To: openconfig/gnmi <[email protected]> Cc: Amish Anand <[email protected]>, Author <[email protected]> Subject: Re: [openconfig/gnmi] Added extension ID to be used for exporting Juniper telemetry header. (#76) [External Email. Be cautious of content] @robshakir commented on this pull request. Apologies, I thought that I'd seen a review of this go by/done one myself. There are a couple of fields that it would be good to have clarified in the proto that you linked. Particularly: * event_timestamp -- this sounds like it should be the same as the timestamp in the Notification? In general, extensions should not create ambiguity between fields (since this hurts interoperability). Can you provide some clarification on this one? * export_timestamp -- is there a reference that determines what the export timestamp means? It would be good to clarify that this is informational w.r.t an internal of your architecture, rather than duplicating the gNMI Notification's timestamp field. Thanks for considering these changes/clarifications. Cheers, r.

________________________________ In proto/gnmi_ext/gnmi_ext.proto<#76 (comment)>:

@@ -46,6 +46,9 @@ enum ExtensionID {

// New extensions are to be defined within this enumeration - their definition // MUST link to a reference describing their implementation. + // Juniper Telemetry header + EID_JUNIPER_TELEMETRY_HEADER = 1; Can you please add a URL to the proto definition / implementation of this header as per the above comment? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#76 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACLX4NGA2YGSTJ3V3CGYUGDRXFC7LANCNFSM4NLXYXGA>.

[amanand]

Hi @robshakir
Can you please share any updates on this?
Thanks
Amish

[gcsl]

On Fri, Jun 19, 2020 at 3:16 PM Amish Anand ***@***.***> wrote: Hi Rob, The timestamps in the extension proto are informational and useful in debugging any issues related to latency or KPI evaluation of the telemetry data. The event_timestamp indicates the time when the event occurs on the device whereas the Notification timestamp is when the device emits the data to the collector.

I believe this is the reason Rob was seeking clarification. The timestamp in the notification is supposed to be the event timestamp, tightly coupled to the data (counter or event), not a serialization or sending timestamp. This is one of the primary motivations for moving to Streaming Telemetry over SNMP in that accurate rates for counters cannot be computed or latency derived if there is no known timestamp associated with the data or event. This is especially problematic when there can be various levels of caching between the event and the serialization of the data. If the timestamps derived for gNMI Notifications are not event timestamps in the existing implementation, that should be fixed. Serialization timestamps might be useful for debugging and could be added as an extension to help identify certain types of problems.

…

The export_timestamp indicates the time when complete telemetry data corresponding to either event or periodic data is sent from the producer. Difference between export_timestamp and event_timestamp will indicate the total time taken to fire the event at producer. Difference between export_timestamp and the timestamp in Notification will indicate the internal latency in the infra. Thanks, Amish From: Rob Shakir ***@***.***> Reply-To: openconfig/gnmi ***@***.***> Date: Wednesday, June 17, 2020 at 3:58 PM To: openconfig/gnmi ***@***.***> Cc: Amish Anand ***@***.***>, Author ***@***.***> Subject: Re: [openconfig/gnmi] Added extension ID to be used for exporting Juniper telemetry header. (#76) [External Email. Be cautious of content] @robshakir commented on this pull request. Apologies, I thought that I'd seen a review of this go by/done one myself. There are a couple of fields that it would be good to have clarified in the proto that you linked. Particularly: * event_timestamp -- this sounds like it should be the same as the timestamp in the Notification? In general, extensions should not create ambiguity between fields (since this hurts interoperability). Can you provide some clarification on this one? * export_timestamp -- is there a reference that determines what the export timestamp means? It would be good to clarify that this is informational w.r.t an internal of your architecture, rather than duplicating the gNMI Notification's timestamp field. Thanks for considering these changes/clarifications. Cheers, r. ________________________________ In proto/gnmi_ext/gnmi_ext.proto< #76 (comment)>: > @@ -46,6 +46,9 @@ enum ExtensionID { // New extensions are to be defined within this enumeration - their definition // MUST link to a reference describing their implementation. + // Juniper Telemetry header + EID_JUNIPER_TELEMETRY_HEADER = 1; Can you please add a URL to the proto definition / implementation of this header as per the above comment? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub< #76 (review)>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ACLX4NGA2YGSTJ3V3CGYUGDRXFC7LANCNFSM4NLXYXGA>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEL4QL4RQVYOM64WYWBSFW3RXO2STANCNFSM4NLXYXGA> .

[robshakir]

Yes - it sounds like event_timestamp is what should be in the Notification of the gNMI message - and that this proto should carry export_timestamp and gnmi_export_timestamp or something similar for the serialisation tracing/debugging.

If we merge with the current behaviour, then this essentially means that we're requiring vendor-specific implementation in this interface, since event_timestamp should be what is in the Notification.

For the record, I think this serialisation debugging/tracing is potentially a useful extension (and is something that we've discussed internally), such that I think there's room for a well-known extension here.

[amanand]

The difference between the Notification timestamp and event_timestamp will be noticeable only in case of Routing sensors due to queuing latency for those sensors. However, I agree the Notification timestamp should indeed be the event timestamp and the one in extension should be termed differently. I will update the proto accordingly and update Juniper implementation accordingly.
I agree that this could be well-known extension with possible couple of fields omitted out. Please do share any timelines for publishing the extension file. We will be keen to take part in any discussions around it.

[robshakir]

Thanks for updating the proto -- please ping the PR when the change is made.

I'm happy for you to start a well-known extension issue to discuss which fields we might want to add here -- alternatively, I can start the issue. Once it's open (with a top-level proposal) I can ping other interested and potentially interested folks.

[amanand]

Hi Rob,
Sorry for pretty late action on this one. I have updated the pull request with the requested details.

Thanks
Amish

[robshakir]

@amanand Is this still live? Apologies, I was on medical leave when you updated this, so I didn't see the change.