Subject: Rtgdir last call review of draft-ietf-teas-actn-framework-11

From: Bruno Decraene <[email-masked]>
Date: Thu, 15 Mar 2018 08:23:46 -0700

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.

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.

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

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

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

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

Related comments
 in §2.1
"The VN can be seen as a set of edge-to-edge links"
may be :s/seen/abstracted

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.

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

§3.4
"while having no impact on other customers. "
This seems to forbid pre-emption of used resources. Why would this be forbidden?
---
§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 --- §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. --- §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. --- §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)

---
§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) ---- §7
OLD: source Aps NEW: source APs

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 21 Mar 2018 15:47:26 +0000

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:[email-masked]] On Behalf Of Bruno Decraene

> Sent: giovedì 15 marzo 2018 16:24

> To: [email-masked]

> Cc: [email-masked]; [email-masked]; [email-masked]

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

> request. The purpose of the review is to provide assistance to the Routing

> ADs.

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

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

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

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

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

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

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

> 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

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

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

 [DC&YL] This was decision of the WG to use this definition in the context of this document. We are not imposing any person/group to use this definition beyond this WG.

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

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

   Networks (ACTN)."

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

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

> e.g. "

> 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

        underlying topology."

 [DC&YL] Agree.

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

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

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

> forbidden?

[DC&YL] Remove this part.

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

--- §5.1 "For

> instance, per an operational policy, the PNC would

> 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

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

--- §5.2.3 " The

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

--- §5.4

> Very nice and useful example. Thanks.

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

> Gbps as used latter)

[DC&YL] Yes.

> 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

---- §7

> OLD: source Aps NEW: source APs

[DC&YL] Agree.

> _______________________________________________

> Teas mailing list

> [email-masked]<mailto:[email-masked]>

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