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
