Subject: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 21 Oct 2020 21:04:52 -0700

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.

---

From: <[email-masked]>
Date: Thu, 22 Oct 2020 08:58:29 +0000

Hi Ben, 

Thank you for the comments. 

An updated version taking into account you review is available at: https://tinyurl.com/auto-iesg-review 

Please find inline replies to track the changes.

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 22 octobre 2020 06:05
> À : The IESG <[email-masked]>
> Cc : [email-masked]; opsawg-
> [email-masked]; [email-masked]; Adrian Farrel
> <[email-masked]>; [email-masked]
> Objet : Benjamin Kaduk's No Objection on draft-ietf-opsawg-model-
> automation-framework-07: (with COMMENT)
> 
> 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.)
> 
> 

[Med] Fixed the nits. Thanks. 
[...]
 
> Is "closed loops" a well-known term in this space?

[Med] It is used in management-related RFCs, e.g., RFC1224.

[...] 
> 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?
> 

[Med] This is typically when the customer asks to connect a new site, requires a strong path diversity (disjoint paths), reach some prefix, etc. These request may require changes to the network.

Updated the text to cite some examples. 

[...]
> security protocols?  Security properties?  Physical security?  What
> is in or out of scope for being covered by any indicated security
> mechanisms?
> 

[Med] This was cited in reference to L3NM. In that model, we manipulate the following security functions: authentication keys, encryption, ACLs. 

Updated the text accordingly. 

[...] 
> 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.
> 

[Med] The L3NM as currently scoped does not allow to expose these capabilities. The text is about identifying the limitations of the current version of the model and describe the "target" architecture where such features are provided. 

Tweaked as follows: 

   L3NM inherits some of data elements from the L3SM.  Nevertheless, the
   L3NM as currently designed in [I-D.ietf-opsawg-l3sm-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 information
   can be provided using, e.g., [I-D.www-bess-yang-vpn-service-pm].  A
   target overall model is depicted in Figure 6. 

[...]

> considerations thereof) are out of scope for this document.

[Med] OK. Added: 

   The communication protocols that make use of a service model between
   a customer and an operator are out of scope.  Relevant security
   considerations should be discussed in the specification documents of
   these protocols.

> 
> 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.

[Med] Good point. Added:

   When a YANG module includes security-related parameters, it is
   recommended to include the relevant information as part of the
   service assurance to track the correct functioning of the security
   mechanisms.

> 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.

[Med] Updated to:

   In order to prevent leaking sensitive information and "confused
   deputy" problem in general, special care should be considered when
   translating between the various layers in Section 4 or when
   aggregating data retrieved from various sources.  Typically,
   authorization and authentication checks should be performed to ensure
   that a data is available to an authorized entity.  The network
   operator must enforce means to protect privacy-related information
   included in customer-facing models.

And added this NEW text:

   Access to some data requires specific access privilege levels.
   Devices must check that a required access privilege is provided
   before granting access to specific data or performing specific
   actions.

[..]
> 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.

[Med] Updated to:

   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.  In
      particular, network models may indicate whether encryption is
      enabled and if so, expose a list of supported encryption schemes
      and parameters.  Refer for example to the encryption feature
      defined in [I-D.ietf-opsawg-vpn-common] and its use in
      [I-D.ietf-opsawg-l3sm-l3nm].

[...]
> 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.

[Med] Updated as follows: 

   Network Element models (listed in 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.  For
   example, the L3VPN service will involve many PEs and require
   manipulating the following modules:

   o  Routing management [RFC8349]

   o  BGP [I-D.ietf-idr-bgp-model]

   o  PIM [I-D.ietf-pim-yang]

   o  NAT management [RFC8512]

   o  QoS management [I-D.ietf-rtgwg-qos-model]

   o  ACLs [RFC8519]

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Oct 2020 08:56:56 -0700

> [Med] It is used in management-related RFCs, e.g., RFC1224.

Ah, thanks for the reference.

> Updated the text to cite some examples. 

Thanks.

>    L3NM as currently designed in [I-D.ietf-opsawg-l3sm-l3nm] does not

Thanks for clarifying.  It seems like the point being made is that the
current L3NM is a bit limited for "our" purposes, and to point to an
extension that can help remedy those limitations, which makes sense.

>    before granting access to specific data or performing specific

Thanks for these!

>       [I-D.ietf-opsawg-l3sm-l3nm].

Nicely said :)

>    o  QoS management [I-D.ietf-rtgwg-qos-model]

Thanks for all the updates!

-Ben