[OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 22 October 2020 04:04 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4629D3A0407; Wed, 21 Oct 2020 21:04:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-opsawg-model-automation-framework@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, adrian@olddog.co.uk
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160333949185.844.18165329242162688909@ietfa.amsl.com>
Date: Wed, 21 Oct 2020 21:04:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/uDiWhjFr7YSrq_JjTxc1UBn3z_8>
Subject: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2020 04:04:52 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-opsawg-model-automation-framework-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sorry that there are so many editorial nits mixed in with actual content-ful comments. I think they are all marked as such, at least. Section 1 o The lack of standard data input/output (i.e., data model) raises many challenges in system integration and often results in manual configuration tasks. (nit) I feel like this would read better with "interfaces" after "input/output". o Ease data inheritance and reusability among the various architecture layers promoting thus a network-wise provisioning instead of device-specific configuration. nit: this looks better with "thus" and "promoting" swapped. o Dynamically fed a decision-making process (e.g., Controllers, nit: s/fed/feed/. Orchestrators) with notifications that will trigger appropriate actions allowing thus to continuously adjust a network (and thus involved resources) to comply the intended service to deliver. nit: the wording here also feels a bit unusual. Perhaps: % o Dynamically fedd a decision-making process (e.g., Controllers, % Orchestrators) with notifications that will trigger appropriate % actions, allowing them to continuously adjust a network (and % thus, the involved resources) to deliver service that conforms % to the intended parameters. Section 2.2 "AP" should probably be in the list as well. We don't seem to define "PM" as such anywhere (though "Performance Monitoring" appears four or five times), but do use it in Appendix A.4.4. Section 3.1 Each level maintains a view of the supported YANG modules provided by low-levels (see for example, Appendix A). nit(?): "lower levels" Section 3.2 Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service filtering request modelled using [RFC8783] will be translated into device-specific filtering (e.g., ACLs defined in [RFC8519]) that to fulfil the service request. nit: s/that to/that/ Section 3.3 Note that it is important to correlate telemetry data with configuration data to be used for closed loops at the different stages of service delivery, from resource allocation to service operation, in particular. Is "closed loops" a well-known term in this space? Section 4.1.2 service requirements in the service request can be met (i.e., whether there is sufficient resources that can be allocated with the requested guarantees). nit: s/is/are/ In addition, a customer may require to change the underlying network infrastructure to adapt to new customer's needs and service requirements. This service modification can be issued following the same Service Model used by the service request. I'm not sure I understand what "underlying network infrastructure" means here -- are there supposed to come into being new routers because the customer issues a request in the Service Model? Section 4.1.3 Performance measurement telemetry model can tie with Service or Network Models to monitor network performance or Service Level Agreement. nit: missing article (e.g., "The performance measurement telemetry model"). Section 4.1.4 Service optimization is a technique that gets the configuration of the network updated due to network changes, incidents mitigation, or nit: s/incidents/incident/ Section 4.2.1 configuration models for network elements; the configuration information includes: [...] o Security I think we need some more details than just "Security". Are these security protocols? Security properties? Physical security? What is in or out of scope for being covered by any indicated security mechanisms? Section 4.2.2 For example, a customer creates an interface "eth-0/0/0" but the interface does not physically exist at this point, then configuration data appears in the <intended> status but does not appear in <operational> datastore. nit: I think this reads better as "if a customer creates" (added "if"). Section 4.2.3 When a configuration is in effect in a device, <operational> nit: "the <operational>". Section 4.3 Another example is to map service parameters in the L3SM into Traffic Engineered (TE) tunnel parameter (e.g., Tunnel ID) in TE model and nit: "parameters" plural. Section 5.1 L3NM inherits some of data elements from the L3SM. Nevertheless, the L3NM does not expose some information to the above layer such as the capabilities of an underlying network (which can be used to drive service order handling) or notifications (to notify subscribers about specific events or degradations as per agreed SLAs). Some of this I'm having a bit of trouble putting this bit together -- specifically the "not" in "does not expose". The rest of the text makes it sound like having the Service layer know some capabilities of the underlying network, or receive notifications from network-layer events, will be useful to the Orchestrator. But the text as-is seems to say that such information will not be provided to the Service layer. Section 5.2 3. The customer exchanges with the Orchestrator the connectivity matrix on the abstract node and explicit paths using the TE nit: I think this is still the "abstract node topology". 4. The telemetry model which augments the VN model and corresponding TE tunnel model can be used to subscribe to performance measurement data and notify all the parameter changes and network nit: "notify" takes an object that is the entity receiving the notifications; the current wording as literally written says that "all the parameter changes and network performance changes" will receive notifications; I believe that the intent is that notifications about such changes are delivered to something (the Orchestrator?), so we should instead say "provide notifications about" or specify the actual object of "notify". Section 5.3 actions are defined and correlated with network events (e.g., allow the NETCONF server to send updates only when the value exceeds a certain threshold for the first time, but not again until the threshold is cleared), which constitute an It's perhaps a little risky to mention such threshold-based behavior without mentioning hysteresis as well. the server via YANG Push subscription [RFC8641], monitors state parameters, and takes simple and instant actions when associated event condition on state parameters is met. ECA notifications nit: "an" or "the" associated event condition. Section 6 I agree with the secdir reviewer that it's worth repeating the disclaimer that customer/provider interfaces (and thus, the security considerations thereof) are out of scope for this document. When the service configuration incluedes "security" parameters (see my comment on §4.2.1), it is important to include the relevant information in the monitoring/assurance pipelines so that the correct functioning of the security mechanisms is tracked. In order to prevent leaking sensitive information, special care should be considered when translating between the various layers in Section 4 or when aggregating data retrieved from various sources. It's also important to perform the necessary authentication and authorization checks (more specifically than just "special care") for operations that cross abstraction-layer boundaries. The "confused deputy problem" may be relevant for some of these cases, and is an important topic to mention as well. Section 6.1 providers. The characterization of a service disruption (including, mean time between failures, mean time to repair), the escalation procedure, and penalties are usually documented in contractual agreements (e.g., Section 2.1 of [RFC4176]). Misbehaving peer nit: pedantically, this is saying that Section 2.1 of RFC 4176 is an example of a contracutal agreement; we may want to say "e.g., as described in Section 2.1 of [RFC4176]" instead. Section 6.2 o Some Service Models may include a traffic isolation clause, appropriate technology-specific actions must be enforced at the underlying network (and thus involved network devices) to avoid that such traffic is accessible to non-authorized parties. It may be worth mentioning the potential misconception that a "virtual private network" always provides privacy against an attacker able to tap the network link(s); only some VPN technologies (can be configured to) do so. In some sense, whether such wire-level encryption is in use could be an aspect exposed at the service model layer. Section A.3 o Network Topologies Model: [RFC8345] defines a base model for network topology and inventories. Network topology data include link resource, node resource, and terminate-point resources. nit: probably all three instances should be "resources" plural? Section A.4 Network Element models (Figure 10) are used to describe how a service can be implemented by activating and tweaking a set of functions (enabled in one or multiple devices, or hosted in cloud infrastructures) that are involved in the service delivery. I don't really see how Figure 10 helps demonstrate *how* "a service can be implemented by activating and tweaking a set of functions"; it seems to just be a listing/categorization of things that have YANG models.
- [OPSAWG] Benjamin Kaduk's No Objection on draft-i… Benjamin Kaduk via Datatracker
- Re: [OPSAWG] Benjamin Kaduk's No Objection on dra… mohamed.boucadair
- Re: [OPSAWG] Benjamin Kaduk's No Objection on dra… Benjamin Kaduk