Hi Benoît, draft authors, WG,
Thank you for the presentations (in several WGs) during IETF 118 and your great
work around model driven telemetry. I have now read the latest version of
draft-claise-opsawg-collected-data-manifest and would like to offer some
comments.
This is really valuable
Hi Rob,
In the session last Monday you raised the question of whether we needed a class
for things that don’t map nicely to the other classes. We have a class which is
effectively the catch-all today:
Thanks Ruediger for you feedback and apologies for my slow reply.
> I'd assume, that's L3 QoS/DiffServ only. The Classification scheme however
> also includes L2 (QoS based drops are a sub-class of
> traffic, not a separate sub-class of L3 only). Does this imply a separate L2
> QoS
Thanks Beniot for your feedback.
Are you suggesting to update the IPFIX forwarding status codes to reflect the
discard classes in draft-opsawg-evans-discardmodel?
On 06/11/2023, 13:03, "Benoit Claise" mailto:benoit.cla...@huawei.com>> wrote:
CAUTION: This email originated from outside of
Hi all,
Ivan raised a comment about indicating in a service request whether this is a
feasibility check only or an actual request for activation. As discussed in
https://github.com/boucadair/attachment-circuit-model/issues/34, this
functionality is natively supported in NETCONF but may not be
Hi all,
The structure of the ip-connection in the spec is inherited from LxNM, which
reflect most deployments I'm aware of. Only one single local IP address is
allowed for an AC as shown in the following tree:
| ...
+--rw ip-connection
| +--rw ipv4 {vpn-common:ipv4}?
Hi all,
Some deployments may imply some dynamicity in the terminating points of a
service (e.g., containers). Providing stable AC references for the service that
uses such ACs, while allowing to managing such dynamic AC is worth to consider.
Leveraging the ac-group-profile and allowing for
