Last Call Review of draft-ietf-teas-actn-framework-11
review-ietf-teas-actn-framework-11-rtgdir-lc-decraene-2018-03-15-00

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