Skip to main content

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