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
<ignacio.dominguezmarti...@telefonica.com>
*Sent:* Monday, November 28, 2022 12:09 AM
*To:* Tianran Zhou <zhoutian...@huawei.com>; Alexander Clemm
<a...@futurewei.com>; opsawg <opsawg@ietf.org>
*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 <zhoutian...@huawei.com>
*Date: *Wednesday, 23 November 2022 at 00:02
*To: *Alexander Clemm <a...@futurewei.com>, IGNACIO DOMINGUEZ
MARTINEZ-CASANUEVA <ignacio.dominguezmarti...@telefonica.com>, opsawg
<opsawg@ietf.org>
*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<a...@futurewei.com>
*收件人： *IGNACIO DOMINGUEZ
MARTINEZ-CASANUEVA<ignacio.dominguezmarti...@telefonica.com>;Tianran
Zhou<zhoutian...@huawei.com>;opsawg<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%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 <opsawg-boun...@ietf.org> on behalf of Alexander Clemm
<a...@futurewei.com>
*Date: *Friday, 18 November 2022 at 17:39
*To: *Tianran Zhou <zhoutian...@huawei.com>, "opsawg@ietf.org"
<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>
*Sent:* Thursday, November 17, 2022 10:49 PM
*To:* Alexander Clemm <a...@futurewei.com>; 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
<mailto:opsawg-boun...@ietf.org>] *代表 *Alexander Clemm
*发送时间**:*2022年11月18日7:40
*收件人**:*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
------------------------------------------------------------------------
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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
