Framework for Abstraction and Control of TE Networks (ACTN)
draft-ietf-teas-actn-framework-15
Yes
(Deborah Brungard)
No Objection
(Alvaro Retana)
(Ignas Bagdonas)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 14 and is now closed.
Warren Kumari
No Objection
Comment
(2018-05-22 for -14)
Unknown
I have a few nits to further improve readability: Section 1: "Traffic Engineered (TE) networks have a variety of mechanisms to facilitate separation of data plane and control plane" s/facilitate separation/facilitate the separation/ ? "This document describes a set of management and control functions used to operate one or more TE networks to construct virtual networks that can be represented to customers" The word "represented" here sounds odd, but I don't really have an alternative -- perhaps just "presented" ? Represented is probably technically correct, but it feels like there should be a more appropriate one... Section 3.4: "In addition, some networks may operate a control plane and as such it is not practical for the customer to directly interface with network elements." Can you please clarify that you mean a TE (or similar) control plane -- I believe that *all* networks have some sort of control plane (and so the "some networks" is false / misleading).
Deborah Brungard Former IESG member
Yes
Yes
(for -14)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2018-05-23 for -14)
Unknown
Thanks to everyone who worked on this document. Kudos in particular for the outstandingly clear and easy-to-understand ASCII-art diagrams. Please fix the following nits: ** There are 16 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 2 instances of lines with control characters in the document.
Alissa Cooper Former IESG member
No Objection
No Objection
(2018-05-24 for -14)
Unknown
This is a well-written document, thanks. In Section 2.2.1 the call out of utility companies seems a bit odd, since it's one specialized version of an enterprise.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -14)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2018-05-23 for -14)
Unknown
Thanks for an easy to read draft. I have a couple of nits: §1, last paragraph: The first sentence is kind of convoluted. Can it be broken into simpler sentences? Figure 1: Is it possible to keep the figure all on the same page? The break makes it easy to miss the entire point, (i.e. why is this 3 tier; I only see 2 tiers)
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-05-23 for -14)
Unknown
Thanks for the clear and easy-to-follow document! I do have a few minor comments, below. Section 3 Please expand OSS and NMS on first usage. Section 3.2 [...] The two functions of the MDSC, namely, multi-domain coordination and virtualization/abstraction are referred to as network-related functions while the other two functions, namely, customer mapping/translation and virtual service coordination are referred to as service-related functions. Starting out with "The two" implies that there are no others, which is contradicted by "the other two" later. So, I'd suggest just starting with "Two functions of the MDSC ...". Section 3.3 Please expand NBI (which appears to only be used once in the document). Section 5.3.2 It seems pretty likely that allowing repeated path computation requests (with different parameters) would allow a malicious MDSC to learn a fair amount of information about the topology that the PNC is attempting to abstract away. This is probably not a huge deal, though. Section 8.3 A key objective of the MDSC is to support the customer's expression of the application connectivity request via its CNC as set of desired business needs, therefore policy will play an important role. nit: "as a set of" Once authorized, the virtual network service will be instantiated via the CNC-MDSC Interface (CMI), it will reflect the customer application and connectivity requirements, and specific service transport needs. nit: this is a comma splice; I'd change the comma before "it" to either a semicolon or a period. (There's a similar issue in the following sentence, too.) Section 9.2 Perhaps we should say something about configuring trust anchors for the PKI, e.g., using a smaller set of trusted CAs than in the Web PKI.
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -14)
Unknown
Martin Vigoureux Former IESG member
No Objection
No Objection
(2018-05-24 for -14)
Unknown
Hello, thank you for this document. I have few questions for clarification: * I'm not sure to understand your definition of Domain. You say: Specifically within this document we mean a part of an operator's network that is under common management. I'm not sure to understand what common means. Also, you add a sentence after that but it didn't help me, in fact it confused me further. Is it the managed entities which have something in common or is that the managing entities which have something in common? In the latter case what would be the common thing? On that matter, I would suggest to capitalise the first letter of all the occurrences of domain which correspond to this definition (with the hope that all of them do). Fig. 1 shows the Customer in relation with the Service Provider but Fig. 2 shows a boundary between Customer and Network Operator. Are the NO and SP merged in Fig. 2? You say: The PNC functions can be implemented as part of an SDN domain controller, a Network Management System (NMS), an Element Management System (EMS), an active PCE-based controller [Centralized] or any other means to dynamically control a set of nodes and that is implementing an NBI compliant with ACTN specification. I have few comments: which ACTN specification are you referring to ? Usually when I read "comply with a specification", I expect to read a MUST/SHOULD in the same sentence. I can understand that you don't want to put a compliance requirement, but then you might want to use another word than "compliant". NBI is not defined/expanded anywhere in the doc. In fact it's the only place where it appears. And in fact seeing it here while Fig. 2 talks about SBI only makes the reader uncertain. One way out of this would be to make it appear on Fig 2. because it's just the same interface, seen from the other direction. You say: A PNC domain includes all the resources under the control of a single PNC. It can be composed of different routing domains and administrative domains, and the resources may come from different layers. Is that consistent with the definition of Domain? More precisely, is that consistent with the last sentence of the Domain definition which says: Network elements will often be grouped into domains based on technology types, vendor profiles, and geographic proximity. 4.1. MDSC Hierarchy Can there be more than two levels in the MDSC hierarchy? In other words, can an MDSC-L for an MDSC-H be itself an MDSC-H for an MDSC-L? As a side note, since I made the mistake while writing this, you have two occurrences of MSDC (instead of MDSC) in the doc .
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-05-18 for -14)
Unknown
I guess this document would have been a great candidate to test SVGs in RFCs :-)
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -14)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -14)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -14)
Unknown