Hello Med,
Thank you for such a prompt reply.
While my comments were non-blocking, I really appreciate your time to reply. I
agree with most of them, for the remaining look below for EV> (and feel free to
ignore)
Regards
-éric
On 18/10/2022, 09:07, "mohamed.boucad...@orange.com"
<mohamed.boucad...@orange.com> wrote:
Hi Éric,
Thank you for the comments.
Please see inline.
I let my co-authors further comment as appropriate.
Cheers,
Med
... %< a lot of text elided ....
>
> ### Relationship with other OPSAWG documents
>
> Just curious: it this work somehow related to
> draft-ietf-opsawg-service-assurance-architecture ? I.e., should
> this document
> add some reference to the service assurance I-Ds ?
[Med] Both drafts refer to RFC8969 which provides the overall framework.
The assurance draft defines an architecture that can consume the data exposed
by means of I-D.ietf-opsawg-yang-vpn-service-pm.
I-D.ietf-opsawg-yang-vpn-service-pm does not assume nor preclude that SAIN is
in place.
If I have to make a change, I would make it in
draft-ietf-opsawg-service-assurance-architecture, e.g.,
EV> up to the SAIN authors of course and not a bad suggestion of yours
OLD:
Service orchestrators use Network service YANG modules that will
infer network-wide configuration and, therefore the invocation of the
appropriate device modules (Section 3 of [RFC8969]). Knowing that a
configuration is applied doesn't imply that the service is up and
running as expected. For instance, the service might be degraded
because of a failure in the network, the experience quality is
distorted, or a service function may be reachable at the IP level but
does not provide its intended function. Thus, the network operator
must monitor the service operational data at the same time as the
configuration (Section 3.3 of [RFC8969]). To feed that task, the
industry has been standardizing on telemetry to push network element
performance information.
NEW:
Service orchestrators use Network service YANG modules that will
infer network-wide configuration and, therefore the invocation of the
appropriate device modules (Section 3 of [RFC8969]). Knowing that a
configuration is applied doesn't imply that the service is up and
running as expected. For instance, the service might be degraded
because of a failure in the network, the experience quality is
distorted, or a service function may be reachable at the IP level but
does not provide its intended function. Thus, the network operator
must monitor the service operational data at the same time as the
configuration (Section 3.3 of [RFC8969]). To feed that task, the
industry has been standardizing on telemetry to push network element
performance information (e.g., [I-D.ietf-opsawg-yang-vpn-service-pm]).
> ### Section 3
>
> Suggest to explain why in `Models are key for automating network
> management
> operations.`.
[Med] RFC8969 provides a detailed discussion about this. I suggest to make
this change:
OLD:
Models are key for automating network management operations.
According to [RFC8969], together with service and network models,
performance measurement telemetry models are needed to monitor
network performance to meet specific service requirements (typically
captured in an SLA).
NEW:
Models are key for automating network management operations (Section 3
of [RFC8969]).
Particularly, together with service and network models,
performance measurement telemetry models are needed to monitor
network performance to meet specific service requirements (typically
captured in an SLA).
EV> good for me
> ### Section 4.3
>
> Just curious about why `mac-num-limit` is used rather than
> `maximum-mac-entries` for consistency with the previous entries?
[Med] Good catch. I suggest we go for "limit-number" to be consistent with
this part from RFC8407:
"Child nodes within a container or list SHOULD NOT
replicate the parent identifier"
EV> good point
>
> ### Section 4.4
>
> Would it be useful to split `inbound-non-unicast` into broadcast
> and multicast ?
>
[Med] This was raised also by Rob during his review
(https://mailarchive.ietf.org/arch/msg/opsawg/bGqJ7V2EvVzJv7H-Xi2Y-jIOsKw/).
Please search for "bum".
EV> still unsure though ;-)
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
