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<a...@futurewei.com<mailto:a...@futurewei.com>> 收件人： IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA<ignacio.dominguezmarti...@telefonica.com<mailto:ignacio.dominguezmarti...@telefonica.com>>;Tianran Zhou<zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>>;opsawg<opsawg@ietf.org<mailto:opsawg@ietf.org>> 主题： 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 <ignacio.dominguezmarti...@telefonica.com> Sent: Monday, November 21, 2022 4:58 AM To: Alexander Clemm <a...@futurewei.com>; Tianran Zhou <zhoutian...@huawei.com>; opsawg@ietf.org 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%7Cfc991751e54546b710f208dacbc010fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638046323051566819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tCn666gG%2F5jeS3dCi6R5Xfxo0PVdzfBSeTkN0mMK7yE%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 <opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>> on behalf of Alexander Clemm <a...@futurewei.com<mailto:a...@futurewei.com>> Date: Friday, 18 November 2022 at 17:39 To: Tianran Zhou <zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>>, "opsawg@ietf.org<mailto:opsawg@ietf.org>" <opsawg@ietf.org<mailto:opsawg@ietf.org>> 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 <zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> Sent: Thursday, November 17, 2022 10:49 PM To: Alexander Clemm <a...@futurewei.com<mailto:a...@futurewei.com>>; opsawg@ietf.org<mailto:opsawg@ietf.org> 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:opsawg-boun...@ietf.org] 代表 Alexander Clemm 发送时间: 2022年11月18日 7:40 收件人: opsawg@ietf.org<mailto:opsawg@ietf.org> 主题: [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
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
