Re: [Teas] Rtgdir last call review of draft-ietf-teas-actn-framework-11

[Leeyoung <[e-mail]>]

Hi Bruno,

Let us know if you think the revision (v.12, as attached in Daniele’s email) is ready to be published.

Thanks & Best regards,
Daniele & Young

From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: Monday, April 02, 2018 8:53 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; Leeyoung <[e-mail]>; [e-mail]
Subject: RE: [Teas] Rtgdir last call review of draft-ietf-teas-actn-framework-11

Thanks a lot Bruno.

The draft will be modified accordingly.
Regarding your last comments:

-        On network slicing: you’re right, it’s more appropriate to speak of TE Network Slicing.
-        On VNS and connectivity service in section 2.2
o   Added the following text in section 2.2:  When a VN is a simple connectivity between two points, the difference between VNS and connectivity service becomes blurred
-        Section 7 clean up
o   OLD:  “In terms of ACTN, a CNC could request a connectivity service (virtual network) between a set of source Aps and destination APs”
o   NEW: In terms of ACTN, a CNC could request a VNS between a set of source Aps and destination APs

Please find attached the updated version and the diff including all of your suggestions.

Thanks a lot
Daniele and Young on behalf of the authors



From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: martedì 27 marzo 2018 15:38
To: Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Teas] Rtgdir last call review of draft-ietf-teas-actn-framework-11

Hi Daniele,

Thanks for accommodating all my comments.

Looks all good to me.

Some details/replies inline [Bruno] but nothing important.

Thanks,
Bruno

From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: Wednesday, March 21, 2018 4:47 PM
To: DECRAENE Bruno IMT/OLN; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Teas] Rtgdir last call review of draft-ietf-teas-actn-framework-11


Hi Bruno,



thanks a lot for the review and apologies for the delay but we took the opportunity of the F2F meeting to review your comments together.

Please see in line.

Daniele & Young on behalf of the authors



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

> From: Teas [mailto:[e-mail]] On Behalf Of Bruno Decraene

> Sent: giovedì 15 marzo 2018 16:24

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

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

> Subject: [Teas] Rtgdir last call review of draft-ietf-teas-actn-framework-11

>

> Reviewer: Bruno Decraene

> Review result: Has Nits

>

> 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-framework-11.txt

> Reviewer: Bruno Decraene

> Review Date: 2018-03-15

> IETF LC End Date: IETF LC not started

> Intended Status: Informational

>

> ==Summary:

> This document is basically ready for publication, but has nits that should be

> considered prior to publication.

>

> ==Comments:

> Overall, the document is clear.

> My main comment is related to the scope of the document, which is not

> obvious to determine for a new reader by reading the beginning of the

> document and in particular the title and the abstract:

>

> 1)Title is "Framework for Abstraction and Control of Traffic Engineered

> Networks". In my personal experience, "Traffic Engineered" may be applied

> to traffic steered using BGP, RSVP-TE, SPRING and also may be IGP alone (by

> "fine"

> tuning the IGP metrics). But reading this document, the introduction restricts

> the scope to "connection-oriented technology". This should probably be

> indicated in the abstract and possibly the title.

>



[DC&YL]  The scope of this document "connection-oriented" traffic engineered network. We added in the first paragraph of the abstract as follows. See the last sentence.



NEW:



   Traffic Engineered networks have a variety of mechanisms to

   facilitate the separation of the data plane and control plane. They

   also have a range of management and provisioning protocols to

   configure and activate network resources.  These mechanisms

   represent key technologies for enabling flexible and dynamic

   networking. The term "Traffic Engineered network" refers to a network

   that uses any connection-oriented technology under the control of a

   distributed or centralized control plane to support dynamic

   provisioning of end-to-end connectivity.



[Bruno] Looks good. Thanks.



> 2) The document seems related to TE for a VPN (*) request. Reading the title

> and the abstract I though the document would be about intra (inter)

> Network Provider TE. May be in the title :s/Networks/VPN Alternatively, I

> like better the description from section 8: "The ACTN framework and

> interfaces are defined to enable traffic engineering for virtual networks." So

> may be "Framework for Abstraction and Control of Traffic Engineered Virtual

> Networks"

>

> (*) or VNS, but in a title/abtract VPN is a better known term.

>



[DC&YL]  VNS are among what ACTN supports, but not limited to. We also support connectivity services (e.g., L1 Connectivity Service). So we would rather stay without changing the title of the document. To clarify we can modify Section 8 sentence: “The ACTN framework and interfaces are defined to enable traffic engineering for virtual networks or connectivity services”. Also we will add in the abstract this aspect clearly as follows in the very last sentence of the abstract:



[Bruno] Well “§2 Overview” seems all about VNS, and section 7 seems to say that a connectivity service is a virtual network: “In terms of ACTN, a CNC could request a connectivity service (virtual network) between a set of source Aps and destination APs”

Also, at least to me, given that the connectivity is limited to the/one customer, this looks like a VPN to me.



NEW:
   This document provides a framework for Abstraction and Control of
   Traffic Engineered Networks (ACTN) to support virtual network services and connectivity services.



[Bruno] Looks good.Thanks.



> ==Minor Issues/Nits:

> ----

>

> 1. Introduction

>

> "to support dynamic provisioning of end-to-end connectivity."

> I'm not sure what "end" refers to, especially since this is the first sentence of

> the document. In the IETF, hence IP centric context, I would assume that

> "end" are the source and destination IP addresses. But usually, AFAIK TE is

> not end to end, but rather from one point in a network to another point in a

> (other) network. And typically within a single network or a single

> administrative domain.

>

[DC&YL] end-to-end is, in ACTN context, access point to access point. One end of access point is PE and the other end of access point is CE. In the context of ACTN, PE has to support TE (e.g., MPLE-TE). From this point of view, “dynamic provisioning of end-to-end connectivity” is used.

[Bruno] OK. Once you have stated that the scope is a connection oriented service “end-to-end” becomes clear (it’s the end of the connection). So looks clear now.



> --

> "Network slices"

> That's a popular term nowdays, but I'm not sure that the definition of

> "Network slices" in this document matches the definition of "Network slices"

> in other documents e.g., 5G networks. In the absence of a common agreed

> definition, may be sticking to the term "network partition" -which is the first

> used in this document, and also used latter- seems safer. (Yes, I've read your

> definition in the terminology section) This is a personal comment. I've seen

> that this has been discussed in the mailing list. Obviously the TEAS WG owns

> the decision.

> --- §1 " TE networks to construct virtual

>    networks that can be represented to customers and that are built

>    from abstractions of the underlying TE networks so that, for

>    example, a link in the customer's network is constructed from a path

>    or collection of paths in the underlying networks.  We call this set

>    of function "Abstraction and Control of Traffic Engineered Networks"

>    (ACTN)."

>

 [DC&YL] This was decision of the WG to use this definition in the context of this document.

[Bruno] OK for me.

 [DC&YL] We are not imposing any person/group to use this definition beyond this WG.

[Bruno] Well, once published as RFC, this is not any more scope to this WG. And having different people have a different understanding of one term, open the way for misunderstanding.



> §2

> "   Furthermore, each network represented to a customer can be built

>    from virtualization of the underlying networks so that, for example,

>    a link in the customer's network is constructed from a path or

>    collection of paths in the underlying network.

>

>    We call the set of management and control functions used to provide

>    these features Abstraction and Control of Traffic Engineered

>    Networks (ACTN)."

>

> I find a significant redundancy. Especially separated by a single page and in a

> document of this size.

>

 [DC&YL] Agree. We would delete the third paragraph:



DELETE: We call the set of management and control functions used to provide

   these features Abstraction and Control of Traffic Engineered

   Networks (ACTN)."

[Bruno] ok, thanks.

> ---

> §2

>

>    "The ACTN framework described in this document facilitates:

>    [...]

>    [...]

>    [...]

>    [...]

>    [...]"

>

> I feel like there is some redundancy and this could be better summarized.

>

>     ". Creation of a virtualized environment allowing operators to view and

>     control multi-domain networks as a single virtualized network."

>

>         The term "virtualized" seems to be used to mean "abstract(ion)" while

>         in the NFV or IT context, it has a different meaning.



[DC&YL] Agree to change to ‘abstract’ from ‘virtualized’



NEW:  "Creation of an abstract environment allowing operators to view and

    control multi-domain networks as a single abstract network."

[Bruno] ok, thanks.





> ---

> "        Network slicing/virtualization and network abstraction may be

>         applied recursively, so a link in one topology may be created

>         by applying slicing and/or abstraction to the links in the

>         underlying topology."

>

> Again, 3 terms seem to be used interchangeably "slicing", "virtualization",

> "abstraction". Wouldn't it be simpler and cleared if the document use one?

> Given the text in the asbtract, the goal of this document is to provide a

> framework for abstraction. So may be the term "abstraction" may be used.

> e.g. "

>        Network abstraction may be

>         applied recursively, so a link in one topology may be created

>         by applying  abstraction to the links in the

>         underlying topology."

> is shorter and probably more readable. May be you meant something else,

> but if so it's not clear what nuance you want to add.

>

[DC&YL]  Agree to change with the suggested text.



NEW: "Network abstraction may be

        applied recursively, so a link in one topology may be created

        by applying abstraction to the links in the

        underlying topology."

[Bruno] ok, thanks.





> Related comments

>  in §2.1

> "The VN can be seen as a set of edge-to-edge links"

> may be :s/seen/abstracted

>

 [DC&YL] Agree.

[Bruno] ok, thanks.





> in §3

> "Virtualization/Abstraction: This function provides"

> It's not crystal clear to me what the different you make between

> virtualization and abstraction. Could you explicit the difference? Or say that

> they are used interchangeably in this document. In both cases, this may call

> for not using both at the same time.

>

[DC&YL] We would delete ‘Virtualization’ from here.

[Bruno] ok, thanks.



> ---

> §2.2.3

>

>    "Network Providers are the infrastructure providers that own the

>    physical network resources and provide network resources to their

>    customers. The network operated by a network provider may be a

>    virtual network created by a service provider and supplied to the

>    network provider in its role as a customer."

>

> First sentence says that the network provider own the physical network.

> Next sentence seems to contradict this. I understand the layered model, but

> nonetheless the definition needs to be valid. (otherwise, a Service Provider

> is itself a (virtualized) Network Provider ) ---

>

[DC&YL] NEW:



   "Network Providers are the infrastructure providers that provision the

   network resources and provide network resources to their

   customers." (note that we rid of the second sentence).



[Bruno] ok, thanks.





> §3.4

> "while having no impact on other customers. "

> This seems to forbid pre-emption of used resources. Why would this be

> forbidden?



[DC&YL] Remove this part.

[Bruno] ok



> ---

> §3.4

>  "Most of the information over this

>         interface is technology agnostic (the customer is unaware of

>         the network technologies used to deliver the service)"

>

> I understand that the information is agnostic of the technology used by

> Network Providers. But technology agnostic seems like a bigger requirement.

> Also, the argument indicated in () seems a bit weak to support this big

> requirement.  For example, the customer is buying a Ethernet VNS. As such,

> the customer is aware of the Ethernet technology and is likely to refer to that

> technology (rather than a technology agnostic information/framework).

> Simplest solution may be to either - remove "(the customer is unaware of

> the network technologies used to deliver the service)" - or :s/technology

> agnostic/agnostic of the technology used by Network Providers



[DC&YL] We would do this: "Most of the information over this interface is agnostic of the technology used by Network Providers." (which is the second choice)

[Bruno] Looks good. Thanks.

(especially as for regular customers, I would assume that they would express their requirement using the technology that they use on their side/AP. e.g. “I want a 1Gb/s Ethernet link between AP1 and AP2”. Asking the customers to rephrase their requirements using the ACTN abstraction does not seem the right way.)







--- §5.1 "For

> instance, per an operational policy, the PNC would

>    not provide any technology specific details (e.g., optical

>    parameters for WSON) in the abstract topology it provides to the

>    MDSC."

>

> OK. But I would assume that abstraction means something bigger than hiding

> details or providing a summary. Hence I'd be more interested in a another

> example specific to abstraction.



[DC&YL] We added, In the first paragraph, expand:

NEW:

   "As discussed in [RFC7926], abstraction is tied with policy of the

   networks.  For instance, per an operational policy, the PNC would

   not provide any technology specific details (e.g., optical

   parameters for WSON) in the abstract topology it provides to the

   MDSC. Similarly, policy of the networks may determine the abstraction type as described in 5.2."



Bruno] OK. Thanks.



--- §5.2.3 " The

>    nodes and links may be physical of abstract while the abstract

>    topology represents the potential of connectivity across the PNC

>    domain."

>

> The sentence is not crystal clear to me. From my understanding of the next

> paragraphs,  I would propose OLD:

>  In this case the PNC

>    exposes an abstract topology that comprises nodes and links.  The

>    nodes and links may be physical of abstract while the abstract

>    topology represents the potential of connectivity across the PNC

>    domain.

>

> NEW:

> In this case, the PNC exposes an abstract topology containing all PNC

> domains border nodes and an abstraction of the connectivity between those

> border nodes.

> This abstraction may contain either physical of abstract nodes/links.



[DC&YL] We agree.

NEW:

In this case, the PNC exposes an abstract topology containing all PNC domains border nodes and an abstraction of the connectivity between those border nodes.

This abstraction may contain either physical or abstract nodes/links.



[Bruno] Looks good. Thanks.





--- §5.4

> Very nice and useful example. Thanks.





--- §6 May be: OLD: Gb NEW: Gb/s (or

> Gbps as used latter)

>

> (at least 10 times in this section)

>



[DC&YL] Yes.

[Bruno] Thanks.



> ---

> §6

> "   A Virtual Network Access Point (VNAP) needs to be defined as binding

>    between the AP that is linked to a VN and that is used to allow for

>    different VNs to start from the same AP."

>

> Sentence is not crystal clear to me. A priori, "between" refers to 2 things.

> One the the "AP", but I can't really parse the second one. (It's may be my

> english but there is probably a way to make it clearer for everyone)



[DC&YL] Agree.



NEW:

 "A Virtual Network Access Point (VNAP) needs to be defined as binding

   between an AP and a VN. It is used to allow for

   different VNs to start from the same AP."



[Bruno] Looks good. Thanks.



---- §7

> OLD: source Aps NEW: source APs



[DC&YL] Agree.

[Bruno] Thanks.







>

> _______________________________________________

> Teas mailing list

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

> https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________



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.