Re: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

[Benoit Claise <[e-mail]>]

Hi Alex,

On 11/28/2022 8:30 PM, Alexander Clemm wrote:
>
> I find this response confusing.  To me this reads that if a non-IETF 
> telemetry feature is used, the data manifest would in fact be up to 
> the implementation i.e. proprietary.  However, it would seem to me 
> that to be useful, the information in the data manifest would need to 
> be standardized, even it is supposed to describe proprietary and/or 
> non-IETF telemetry mechanisms.
>
Exactly. This draft targets YANG push but knowing that this telemetry 
world is not exclusively focused on YANG push, we should be open to 
other mechanisms as well. And if we do, we "should spell out 
specifically how", as you wrote.
>
> So, if gNMI is supposed to be covered, it should spell out 
> specifically how.  Of course, whether it makes sense trying to 
> managing non-IETF mechanisms (which have their own mechanisms) via an 
> IETF standard may be another question; I agree with Tianran here.
>
> Either way, I think at a minimum further clarification in the draft is 
> needed.
>
Agreed.

Thank you.

Regards, Benoit
>
> --- Alex
>
> *From:* IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA 
> <[e-mail]>
> *Sent:* Monday, November 28, 2022 12:09 AM
> *To:* Tianran Zhou <[e-mail]>; Alexander Clemm 
> <[e-mail]>; opsawg <[e-mail]>
> *Subject:* Re: [OPSAWG] Manifest need? Re: 
> draft-claise-opsawg-collected-data-manifest
>
> Hi Tianran,
>
> I understand your point. In the beginning, the MDT collector would 
> provide the Data Collection Manifest as this component knows about the 
> MDT subscription details depending on the type of protocol (e.g., 
> gNMI, YANG Push). But ideally, the network platform would implement 
> the manifest so subscription information can also be streamed directly 
> from the platform, regardless of which MDT protocol is used. This is 
> explained in the draft as follows:
>
> It is expected that the Data Manifest is streamed directly from the
>
>    network equipment, along with the telemetry feature.  If a platform
>
>    streaming telemetry does not support yet the YANG modules from the
>
>    Data Manifest specified in this document, the collector could
>
>    populate the Data Manifest from available information from the
>
>    platform.  However, this option requires efforts on the collector
>
>    side, as the information gathered in the Data Manifest proposed in
>
>    this document could be scattered among various standard and vendor-
>
>    specific YANG modules [RFC8199], that depend on the platform.
>
> Hope this answered your question.
>
> Many thanks!
>
> Best regards,
>
> Nacho.
>
> *From: *Tianran Zhou <[e-mail]>
> *Date: *Wednesday, 23 November 2022 at 00:02
> *To: *Alexander Clemm <[e-mail]>, IGNACIO DOMINGUEZ 
> MARTINEZ-CASANUEVA <[e-mail]>, opsawg 
> <[e-mail]>
> *Subject: *RE: [OPSAWG] Manifest need? Re: 
> draft-claise-opsawg-collected-data-manifest
>
> Hi Nacho,
>
> I am not sure if I really understand this argument.
> There are different lines, like Yang push, gnmi, private implementations. If they cannot follow IETF subscription, i.e., Yang push, how could they follow an IETF manifest? I mean they will use their own way to indicate the collection information.
> I mean I think we should only consider Yang push here.
>
> Best,
> Tianran
>
> ------------------------------------------------------------------------
>
>
> Sent from WeLink
>
> *发**件人： *Alexander Clemm<[e-mail]>
>
> *收件人： *IGNACIO DOMINGUEZ 
> MARTINEZ-CASANUEVA<[e-mail]>;Tianran 
> Zhou<[e-mail]>;opsawg<[e-mail]>
>
> *主**题**： *RE: [OPSAWG] Manifest need? Re: 
> draft-claise-opsawg-collected-data-manifest
>
> *时间**： *2022-11-22 02:09:12
>
> Thank you for clarifying.  Yes, I think it will be good to make this 
> more explicit to the draft (and perhaps hint also to at the 
> alternative option of subscribing to the subscription configuration if 
> it were only YANG-Push (as opposed to other mechanisms) that was being 
> used, to more clearly differentiate the delta provided by this draft).
>
> Best
>
> --- Alex
>
> *From:* IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA 
> <[e-mail]>
> *Sent:* Monday, November 21, 2022 4:58 AM
> *To:* Alexander Clemm <[e-mail]>; Tianran Zhou 
> <[e-mail]>; [e-mail]
> *Subject:* Re: [OPSAWG] Manifest need? Re: 
> draft-claise-opsawg-collected-data-manifest
>
> Hi Alex,
>
> The purpose of the Data Collection Manifest is to cover all possible 
> MDT mechanisms, not only YANG Push. There are other mechanisms like 
> gNMI, which rely on subscriptions based on YANG path, for which we 
> need the context of the subscription (e.g., on-change, 
> suppress-redundancy). Additionally, vendors like Cisco or Huawei also 
> implement other MDT mechanisms based on YANG Path.
>
> For more details, you can follow an internal discussion he had on 
> github: 
> https://github.com/JeanQuilbeufHuawei/draft-collected-data-manifest/pull/30 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJeanQuilbeufHuawei%2Fdraft-collected-data-manifest%2Fpull%2F30&data=05%7C01%7Calex%40futurewei.com%7C250b9213f5ba48d4a49308dad117d2f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638052197539444125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Et6LdF8I2OPWWt9oCCFzLSJKM6dsK5V9peLWjjumjNs%3D&reserved=0>
>
> In any case, I agree that we can better clarify this aspect in the draft.
>
> Many thanks for your feedback!
>
> Best regards,
>
> Nacho.
>
> *From: *OPSAWG <[e-mail]> on behalf of Alexander Clemm 
> <[e-mail]>
> *Date: *Friday, 18 November 2022 at 17:39
> *To: *Tianran Zhou <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Subject: *Re: [OPSAWG] Manifest need? Re: 
> draft-claise-opsawg-collected-data-manifest
>
> So, saving the invocation of one command to establish the 
> “meta-subscription”, that’s all this is for?  And for this we are 
> asking implementors to create what is in effect redundant 
> instrumentation?  This seems a lot of effort for a small saving.
>
> As a thought, even in that case, would you even need a redundant 
> YANG-data model, or would it make sense to instead augment the 
> existing model with an additional parameter instead “provide manifest 
> info”, which adds implicitly a subscription to the subscription info 
> to the subscription itself?  Such an alternative could be accomplished 
> by augmenting such a parameter into the existing model, and save the 
> need to create YANG data instrumentation that is basically redundant, 
> hence reduce the complexity of implementations.
>
> --- Alex
>
> *From:* Tianran Zhou <[e-mail]>
> *Sent:* Thursday, November 17, 2022 10:49 PM
> *To:* Alexander Clemm <[e-mail]>; [e-mail]
> *Subject:* RE: Manifest need? Re: 
> draft-claise-opsawg-collected-data-manifest
>
> Hi Alex,
>
> I think this is a very good discussion. I raised this question before 
> in the mailing list.
>
> I think there may be some benefits:
>
> 1. The meta data can always go with the telemetry data, without 
> explicit subscription. This facilitates the close loop automation.
>
> 2. Another subscription to the subscription information may make the 
> management complex, since we put all the subscriptions in one list.
>
> Best,
>
> Tianran
>
> *发件人**:*OPSAWG [mailto:[e-mail] 
> <mailto:[e-mail]>] *代表 *Alexander Clemm
> *发送时间**:*2022年11月18日7:40
> *收件人**:*[e-mail]
> *主题**:*[OPSAWG] Manifest need? Re: 
> draft-claise-opsawg-collected-data-manifest
>
> Hello draft-claise-opsawg-collected-data-manifest coauthors,
>
> I just wanted to follow up on my comment at the microphone in London 
> regarding draft-claise-opsawg-collected-data-manifest.
>
> Clearly, there is a need to preserve context to be able to correctly 
> interpret data after it has been collected.  That being said, as 
> currently stated, the draft appears to overspecify some of those 
> things, defining some YANG data that IMHO is not actually needed as 
> the same can already be accomplished.  This concerns the specifics 
> about the subscription itself.
>
> RFC 8641 includes a YANG model that reflects for each subscription how 
> it is configured (whether configured directly or established by RPC), 
> including the selection filter, the update trigger, the period and 
> anchor time (in case of periodic subscription), dampening periods and 
> excluded changes (in case of on-change subscription), etc. The 
> corresponding YANG data can be itself be subscribed to, or retrieved 
> on demand, just like any other kind of YANG data.
>
> I am therefore not quite sure what the proposed manifest would provide 
> that couldn't be accomplished already.  The suggestion to retain the 
> subscription data along with the subscribed data makes a lot of sense 
> but would appear to be a practice that will be up to the management 
> application to implement, with the mechanism already provided.  (This 
> could of course be included as a description of a recommended practice 
> in the draft.)  Or is there something else that is missing?
>
> If there is indeed a delta that cannot be otherwise accomplished, my 
> suggestion would be to add text to the draft that clearly describes 
> the possibility of subscribing to subscription configuration data, 
> then explaining the functional delta that your draft covers in 
> addition to that.
>
> Thanks
>
> --- Alex
>
> ------------------------------------------------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
> destinatario, puede contener información privilegiada o confidencial y 
> es para uso exclusivo de la persona o entidad de destino. Si no es 
> usted. el destinatario indicado, queda notificado de que la lectura, 
> utilización, divulgación y/o copia sin autorización puede estar 
> prohibida en virtud de la legislación vigente. Si ha recibido este 
> mensaje por error, le rogamos que nos lo comunique inmediatamente por 
> esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is confidential and 
> privileged information intended only for the use of the individual or 
> entity named above. If the reader of this message is not the intended 
> recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. 
> If you have received this transmission in error, do not read it. 
> Please immediately reply to the sender that you have received this 
> communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
> senhoria o destinatário indicado, fica notificado de que a leitura, 
> utilização, divulgação e/ou cópia sem autorização pode estar proibida 
> em virtude da legislação vigente. Se recebeu esta mensagem por erro, 
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
> proceda a sua destruição
>
> ------------------------------------------------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
> destinatario, puede contener información privilegiada o confidencial y 
> es para uso exclusivo de la persona o entidad de destino. Si no es 
> usted. el destinatario indicado, queda notificado de que la lectura, 
> utilización, divulgación y/o copia sin autorización puede estar 
> prohibida en virtud de la legislación vigente. Si ha recibido este 
> mensaje por error, le rogamos que nos lo comunique inmediatamente por 
> esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is confidential and 
> privileged information intended only for the use of the individual or 
> entity named above. If the reader of this message is not the intended 
> recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. 
> If you have received this transmission in error, do not read it. 
> Please immediately reply to the sender that you have received this 
> communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
> senhoria o destinatário indicado, fica notificado de que a leitura, 
> utilização, divulgação e/ou cópia sem autorização pode estar proibida 
> em virtude da legislação vigente. Se recebeu esta mensagem por erro, 
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
> proceda a sua destruição
>
>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg