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

Request Review of draft-ietf-teas-actn-framework
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-03-14
Requested 2018-02-13
Requested by Deborah Brungard
Other Reviews Genart Last Call review of -13 by Peter Yee (diff)
Secdir Last Call review of -13 by Catherine Meadows (diff)
Opsdir Last Call review of -13 by Scott Bradner (diff)
Genart Telechat review of -14 by Peter Yee (diff)
Comments
Prep for LC
Review State Completed
Reviewer Bruno Decraene
Review review-ietf-teas-actn-framework-11-rtgdir-lc-decraene-2018-03-15
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/Mt0yH4BjQLYqv5hSp0wlRs7KztE
Reviewed rev. 11 (document currently at 15)
Review result Has Nits
Draft last updated 2018-03-15
Review completed: 2018-03-15

Review
review-ietf-teas-actn-framework-11-rtgdir-lc-decraene-2018-03-15

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