Subject: [RTG-DIR] RtgDir Early review: draft-ietf-teas-actn-requirements-08.txt

From: "Papadimitriou, Dimitri (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 28 Feb 2018 18:59:43 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-teas-actn-requirements-08.txt
Reviewer: Dimitri Papadimitriou 
Review Date: 28-02-2018
IETF LC End Date: date-if-known 
Intended Status: Informational

Summary: 

I have some concerns about this document that I think should be resolved before it is submitted to the IESG.

Readability should be improved: the document is not easy to read for people not mastering terms not used in their canonical/CS sense. 

It may be appropriate to reconsider the title of this document since most requirements are qualitative/functional (very limited considerations about quantitative aspects) or alternatively clarify this point in the abstract.

Comments:

Section 1: several terms are used without providing reference to their definition. Examples include "orchestration" (is it used as synonym of coordination -- defined in ACTN-FRAME), "collation", "hierarchical abstraction" (do authors refer to the well-defined notion of recursive abstraction ? and what is the minimum of #recursion levels to be supported/expected).

Section 1: the statement " Provision via a data model of a computation scheme..." is to be clarified: does this requirement imply that the "computational methods" must be using the same data model as the one used for network control/operation ?

Section 1: the document refers to various policies (= mapping from state to actions; hence, at several places the use of the term "policy" seems inadequate/refers to something else); more importantly, this raises the following question: what about detection and resolution of policy conflicts e.g. any requirement in terms of automation in the handling of run-time conflicts ?

Section 2.1: Clarify the relation between Req.1 and .3, it looks as if Req.1 is a very generic statement whose specifics are documented in Req.3

Section 2.1: Concerning objective functions document if the requirement implies that "any" of them would have to be supported or if a min.set of obj.functions have to be supported on a path and/or graph basis (if this min.set is unknown at this point in time mention it explicitly).

Section 2.1: Req.8 Would be appropriate to explicit the term " Trust domain verification" between which entities (ext/int to what ?), what this verification implies ?

Section 2.2: Req.1 VNS delete/modify/etc. but no "provisioning" action listed, any reason ?

Section 2.2: Req.3 concerning the " Alternative path computation" does it mean that an BGP alternate path would be satisfactory as long as connectivity is ensured ? 

Section 2.2: Req.4 in the headline of the section the term restoration is distinguished from protection, in this requirement not; does it mean that for path protection there is no involvement besides end-points ? In Req.5 the " fast recovery/reroute" technique is being used instead. Suggestion is made here to stick to one terminology throughout the whole document.

Section 2.2: Req.5 specify for the so-called "Large-scale VNS operation" whether the answer to the operation is expected at the same level of granularity. Example: query all leaves of a tree is a single command but the requester could be in turn overloaded if 100k leaves reply individually.

Thanks,
-dimitri.

---

From: Leeyoung <[email-masked]>
Date: Thu, 1 Mar 2018 04:50:50 +0000

Hi Dimitri,

Thanks for your time and providing valuable comments. Please see inline for my response to your comments.
Kindly let me know if further clarifications/changes are needed.

Best regards,
Young

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Papadimitriou, Dimitri (Nokia - BE/Antwerp)
Sent: Wednesday, February 28, 2018 1:00 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [RTG-DIR] RtgDir Early review: draft-ietf-teas-actn-requirements-08.txt

Hello,

Summary:

YOUNG>> OK. I can add  "functional" in the abstract and in the introduction as follows:

OLD:
This document provides a set of requirements for abstraction and
   control of Traffic Engineering networks to facilitate virtual
   network operation via the creation of a single virtualized network
   or a seamless service.

NEW:
This document provides a set of functional requirements for abstraction and
   control of Traffic Engineering networks to facilitate virtual
   network operation via the creation of a single virtualized network
   or a seamless service.
---------------------------------------------------
Comments:

YOUNG>> For orchestration, as you pointed out, it is used as synonym of coordination. So it would be best to replace orchestration to coordination and will refer this to [ACTN-FRAME].

In the second paragraph in the Introduction Section:

OLD:

ACTN refers to the set of virtual network service operations needed
   to orchestrate, control and manage

NEW:

ACTN refers to the set of virtual network service operations needed
   to coordinate, control and manage

And the third dashed item:

OLD:

- Orchestration of end-to-end virtual network services and
        applications via allocation of network resources to meet
        specific service, application and customer requirements.

NEW:
- Coordination of end-to-end virtual network services and
        applications via allocation of network resources to meet
        specific service, application and customer requirements.

YL>> For collation, this is just an English word to mean "collecting in an organized way". Do you have a better suggestion to use other word than "collation"?

YL>> For hierarchical abstraction, we meant recursive abstraction across controller hierarchy. How about the changes as follows:

OLD:
        through a process of
        hierarchical abstraction to present a customer with a single
        virtual network. This is achieved by presenting the network
        domain as an abstracted topology to the customer via open and
        programmable interfaces. Hierarchical abstraction allows for
        the recursion of controllers in a customer-provider
        relationship.
NEW:
        through a process of
        recursive abstraction to present a customer with a single
        virtual network. This is achieved by presenting the network
        domain as an abstracted topology to the customer via open and
        programmable interfaces. Recursive abstraction allows for
        the recursion of abstracted data in a hierarchy of controllers.

We can add a new sentence following the above paragraph:

NEW: It is expected that the recursion levels should be at least three levels: customer level, multi-domain network level, and domain network level.
-----------------------------------------------

YOUNG>> Yes, it is confusing. I would delete computational methods from the sentence:

OLD:
Provision via a data model of a computation scheme and virtual
        control capability to customers who request virtual network
        services. Note that these customers could, themselves, be
        service providers.

NEW:
Provision via a data model and virtual
        control capability to customers who request virtual network
        services. Note that these customers could, themselves, be
        service providers.
------------------------------------------------------------

YOUNG>> OK. In many places where 'policy' is used, 'preference' would be a good replacement. How about:

In Section 2.1, Requirement #1:

OLD:
The customer MUST be able to express VNS
   policy that captures Service Level Agreements (SLA) associated with
   virtual network service (e.g., Endpoint selection policy, routing
   policy, time-related policy, etc.)

NEW:
The customer MUST be able to express VNS
   preference that captures Service Level Agreements (SLA) associated with
   virtual network service (e.g., Endpoint selection preference, routing
   preference, time-related preference, etc.)

Requirement #6:

OLD:
Customer MUST be able to define and convey service/preference
   requirements for multi-destination applications (e.g., set of
   candidate sources/destinations, thresholds for load balancing,
   disaster recovery policy, etc.)

NEW:
Customer MUST be able to define and convey service/preference
   requirements for multi-destination applications (e.g., set of
   candidate sources/destinations, thresholds for load balancing,
   disaster recovery preference, etc.)

Requirement #7:
OLD:
The customer MUST be able to define performance monitoring
   parameters and its associated policy such as frequency of report,
   abstraction/aggregation level of performance data (e.g., VN level,
   tunnel level, etc.) with dynamic feedback loop from the network.

NEW:
The customer MUST be able to define performance monitoring
   parameters and its associated preference such as frequency of report,
   abstraction/aggregation level of performance data (e.g., VN level,
   tunnel level, etc.) with dynamic feedback loop from the network.

In Section 2.2, Requirement #1: Replace the word 'policy' with 'service'

OLD:
- VNS Monitor: Upon customer's VNS performance monitoring
          setup, the network MUST be able to support VNS level
          Operations, Administration and Management (OAM) Monitoring
          under policy agreement.

NEW:
- VNS Monitor: Upon customer's VNS performance monitoring
          setup, the network MUST be able to support VNS level
          Operations, Administration and Management (OAM) Monitoring
          under service agreement.

---------------------------------------------------------

YOUNG>> Req.1 is VNS level and Req.3 is Specific network level such as multi-domain and multi-layer. So these two are separate requirements.
---------------------------------------------------

YOUNG>>  Objective Function is a choice of the customer - it can be one objective function or a combination of multiple objective functions with weight, etc.
OLD:
VN Topology Service-specific Objective Functions (e.g.,
          maximum bandwidth, minimum latency, minimum hops, etc. and
          any combination of them).

NEW:
VN Topology Service-specific Objective Functions (e.g., any of the objective functions to be supported such as
          maximum bandwidth, minimum latency, minimum hops, etc. or
          any combination of them with weight).
----------------------------------------------------

YOUNG>>  It means: Trust domain verification between a customer entity and a network entity.  It verifies if a trust relationship has been establishes between these entities.

OLD:
- Trust domain verification (external entity versus internal entity)

NEW:
- Trust domain verification between a customer entity and a network entity.  It verifies if a trust relationship has been establishes between these entities.
-------------------------------------------------------------------

YOUNG>> You are absolutely correct. It should've listed VN Creation. I will add the following in the first dashed list.

NEW:
- VNS Create: Upon customer's VNS creation request, network MUST be able to create VNS.
-------------------------------------------------------------------

YOUNG>> Actually not. Here what we meant is, given the domain sequence determined by the MDSC, if any domain cannot find its domain path (which is a part of the end-to-end path), the alternative path computation should be attempted by the MDSC. In such case, the MDSC should try different domain entry points (i.e. ASBRs) of the same domain sequence or a completely different domain sequence. Here we are referring to TE-path.
-------------------------------------------------------------------

YOUNG>> Agree. Requirement 4, the headline should be Protection. Req. 5 talks about real-time recovery/reroute when protection schemes fail.  Will do the following:

OLD:  4. Requirement 4: End-to-End Path Restoration

   End-to-end Path Restoration Operations MUST be provided with
   seamless coordination between domain-level recovery schemes and
   cross-domain recovery schemes.

NEW: 4. Requirement 4: End-to-End Path Protection

   End-to-end Path Protection Operations MUST be provided with
   seamless coordination between domain-level protection schemes and
   cross-domain protection schemes.
------------------------------------------------

YOUNG>>  Here we meant for VNS instantiation to be large-scale in term of handling VN service by the network. Perhaps, I would reword as follows:

OLD: Large-scale VNS operation (e.g., the ability to query tens
           of thousands of nodes, and to examine tens of thousands of
           connectivity requests) for time-sensitive applications.

NEW: Large-scale VNS operation (e.g., the ability to process tens of thousands of
           connectivity requests by the network) for time-sensitive applications.

Thanks,
-dimitri.