Hello Med and Eric, I have added the reference to draft-ietf-opsawg-yang-vpn-service-pm in the sain architecture draft.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-architecture-11 Thanks ! Jean > -----Original Message----- > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Eric Vyncke > (evyncke) > Sent: Tuesday 18 October 2022 08:23 > To: mohamed.boucad...@orange.com; The IESG <i...@ietf.org> > Cc: opsawg@ietf.org; opsawg-cha...@ietf.org; draft-ietf-opsawg-yang-vpn- > service...@ietf.org > Subject: Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg- > yang-vpn-service-pm-13: (with COMMENT) > > 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 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
