Re: [Teas] RtgDir Early review: draft-ietf-teas-actn-requirements-08.txt

[Leeyoung <[e-mail]>]

Hi Dimitri,



Thank you so much for your timely review and good suggestions. I think we are converging. Please see inline for my comments.

Let me know if your have any further comments.



Best regards,

Young



-----Original Message-----
From: rtg-dir [mailto:[e-mail]] On Behalf Of Papadimitriou, Dimitri (Nokia - BE/Antwerp)
Sent: Thursday, March 01, 2018 3:58 AM
To: Leeyoung <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-teas-actn-requirements-08.txt



Hello,



Thanks for the prompt answer. Here below few points that would deserve further clarification. All the rest OK for me.



> YL>> For collation, this is just an English word to mean "collecting

> YL>> in an

> organized way". Do you have a better suggestion to use other word than

> "collation"?



[DP] Referring to "Collation of the resources from multiple TE networks" I understand the purpose is to: examine/compare (a copy of the data with the original to find differences (errors or changes)) and combine/arrange into a proper numerical or logical sequence... in this context do you mean the "Collation of the identifiers and other attributes of the resources describing multiple TE networks" or alike ?



YOUNG>> Thanks for the suggested wording. This is good.

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

> 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

>

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



[DP] I don't get it "Requirement 1: Virtual Network Service (VNS) creation" vs. "Requirement 3: VNS Instantiation ("Please create a VNS for me")" but I might have missed something.



YOUNG>> Sorry, I got confused with Section 2.2. You're right. Req 3 is specifics of Req 1. I will add the following under Req 3:



NEW: Requirement 3 provides specific details of Requirement 1.

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

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

>

> YOUNG>>  Objective Function is a choice of the customer - it can be

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



[DP] The objective function is defined as the cost, profit, or some other function, e.g., load, whose value is to be either maximized or minimized (over the set of feasible alternatives); thus either you indicate "load" when referring to an objective function or alternatively you may explicit the query itself "find the path that minimizes the load function value"



YOUNG>> Here we are talking about customer ability to specify what kind of objective functions for which the paths in the VN should be optimized among the set of feasible alternatives. There are well defined set of objective functions already we can refer to such as RFC 5541 but there can be more than those defined in RFC 5541. So how about:



NEW:  VN Topology Service-specific Objective Functions (e.g.,  a set of objective functions as defined in [RFC5541] to be supported on the paths, but not limited to.)

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



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

>

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



[DP] Then, I would suggest to indicate "Alternative TE path computation" to avoid any confusion.



YOUNG>> Agree. Thanks.



Many thanks,

-dimitri.





> -----Original Message-----

> From: Leeyoung [mailto:[e-mail]]

> Sent: Thursday, March 01, 2018 5:51 AM

> To: Papadimitriou, Dimitri (Nokia - BE/Antwerp)

> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> Subject: RE: RtgDir Early review:

> draft-ietf-teas-actn-requirements-08.txt

>

> 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:[e-mail]] On Behalf Of

> Papadimitriou, Dimitri (Nokia - BE/Antwerp)

> Sent: Wednesday, February 28, 2018 1:00 PM

> To: [e-mail]<mailto:[e-mail]>

> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> Subject: [RTG-DIR] RtgDir Early review:

> draft-ietf-teas-actn-requirements-

> 08.txt

>

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

>

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

>

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

>

> YOUNG>> For orchestration, as you pointed out, it is used as synonym

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

> YL>> in an

> organized way". Do you have a better suggestion to use other word than

> "collation"?

>

> YL>> For hierarchical abstraction, we meant recursive abstraction

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

> -----------------------------------------------

>

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

>

> YOUNG>> Yes, it is confusing. I would delete computational methods

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

> ------------------------------------------------------------

>

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

>

> YOUNG>> OK. In many places where 'policy' is used, 'preference' would

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

>

> ---------------------------------------------------------

>

> 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

>

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

> ---------------------------------------------------

>

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

>

> YOUNG>>  Objective Function is a choice of the customer - it can be

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

> ----------------------------------------------------

>

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

>

> YOUNG>>  It means: Trust domain verification between a customer entity

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

> -------------------------------------------------------------------

>

> Section 2.2: Req.1 VNS delete/modify/etc. but no "provisioning" action

> listed, any reason ?

>

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

> -------------------------------------------------------------------

>

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

>

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

> -------------------------------------------------------------------

>

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

>

> YOUNG>> Agree. Requirement 4, the headline should be Protection. Req.

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

> ------------------------------------------------

>

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

>

> YOUNG>>  Here we meant for VNS instantiation to be large-scale in term

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