Subject: [Gen-art] Genart last call review of draft-ietf-teas-actn-framework-13

From: Peter Yee <[email-masked]>
Date: Tue, 01 May 2018 22:21:18 -0700

Reviewer: Peter Yee
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-teas-actn-framework-13
Reviewer: Peter Yee
Review Date: 2018-05-01
IETF LC End Date: 2018-04-30
IESG Telechat date: 2018-05-24

Summary: This draft is a framework for taking an abstract look at how traffic
engineered networks can be provisioned and controlled.  There are some issues
with looseness in terms that make it more difficult to understand than it needs
to be. [Ready with issues]

Major issues: None

Minor issues:

Page 12, Figure 2: Figure 1 and the preceding text say that it’s
Customer->Service Provider->Network Provider, but then here you have a business
boundary between a customer and a network provider.  I get that the model can
be recursive, but I find it confusing that you’re discussing an architecture
that throws out the part of the terminology of the model that was just
presented two pages previously.  This is symptomatic of a problem I have with
the looseness of the language in the document in which terms like (point, node)
and (service provider, network provider, operator) are used interchangeably,
even in contravention of how they are defined in the document.  This makes
sections 2 and 3 somewhat confusing.

Page 12, Section 3.1, 1st sentence: Wait, 2.2.2 says that VNS are delivered by
the service providers, not network providers.  Yes, SPs can also be customers
of infrastructure-only network providers (2.2.2, para 2), but this muddles the
picture.  If CNCs are Service Provider devices (functions), then I withdraw the
comment, but the naming (CNC) doesn't make it obvious that these are part of an
SP.  The model given in Figure 1 and Section 2 strikes again.

Nits/editorial comments:

General:

Expand acronyms on initial use, particularly if the are not marked as common in
the RFC Editor's list:
https://www.rfc-editor.org/materials/abbrev.expansion.txt.

Use a comma after each "e.g." (only a couple were missing).

Change "multi domain" to "multidomain" (or "multi-domain").  Make a similar
change for "inter domain".

Separate "Gbps" from the preceding number throughout the document.

Specific:

Page 4, 1st full paragraph, last sentence: make "function" plural.

Page 5, 2nd bullet item: append a comma after "application".

Page 5, Section 2.1, 1st sentence: append a blank line after this sentence to
separate it from the following bullet item.

Page 6, 1st partial paragraph, 1st partial sentence: make the last use of
"network" plural.

Page 6, 1st partial paragraphk, 1st full sentence: change "Network" to
"network".

Page 6, 3rd bullet item: isn't this redundant since the 2nd bullet item
essential defines it as well, especially with the reference to RFC 7926
[section 1.1.9]?

Page 7, 1st bullet item: delete two excess, blank lines above the bullet items.

Page 11, 1st bullet item: this is basically a description of the MDSC.  You
manage to make a forward reference to PNC here.  Why not just drop MDSC in
there as well?

Page 11, last bullet item: change "South Bound" to "Southbound", as used later
in the document.

Page 18, section 5.2.1, 1st sentence: change "information. I.e." to
"information, i.e.".

Page 20, 1st sentence:  It might be reasonable to change "modes" to "types" to
match the usage in the following two bullet items.

Page 20, 1st bullet item: append a comma after "topology" and delete the second
occurrence of "type".

Page 20, 2nd bullet item: append a comma after "topology".

Page 25, Figure 10: explain what the line thicknesses mean.  It's almost
certainly not what was meant in Figure 9.

Page 26, 1st sentence after Table 1: what kind of provider is being discussed
here, network or service?  Does it matter?  Does the separation of such in the
model matter?  (See Minor Issues.)

Page 27, section 6.1, 1st paragraph, 1st sentence: append a comma after "APs".

Page 28, Table 4: It's not really clear to me how AP3 ends up with 40 Gbps
bandwidth.  It seems like you might be reusing assumptions from the previous
example, but you should really set up the multi-homing example more clearly. 
In the previous example, AP2 was in a different domain, so it's not apparent
why it would have 40 Gbps in this example.

Page 33, section 9, 2nd paragraph: append "of whether" after "regardless".

---

From: Leeyoung <[email-masked]>
Date: Fri, 4 May 2018 15:07:44 +0000

Hi Peter,

Thanks a lot for your thorough review and providing us with a list of good comments.

We accepted all your comments and created a diff file for your convenience.

Please see DC&YL>> for our response to your comments.

Let us know if you have any further comments. Thanks.

Best regards,

Young and Daniele

> -----Original Message-----

> From: Peter Yee [mailto:[email-masked]]

> Sent: mercoledì 2 maggio 2018 07:21

> To: [email-masked]

> Cc: [email-masked]; [email-masked];

> [email-masked]

> Subject: Genart last call review of draft-ietf-teas-actn-framework-13

> Review Team (Gen-ART) reviews all IETF documents being processed by

> the IESG for the IETF Chair.  Please treat these comments just like

> any other last call comments.

> Summary: This draft is a framework for taking an abstract look at how

> traffic engineered networks can be provisioned and controlled.  There

> are some issues with looseness in terms that make it more difficult to

> understand than it needs to be. [Ready with issues]

> Customer->Service Provider->Network Provider, but then here you have a

> Customer->business

> boundary between a customer and a network provider.  I get that the

> model can be recursive, but I find it confusing that you’re discussing

> an architecture that throws out the part of the terminology of the

> model that was just presented two pages previously.  This is

> symptomatic of a problem I have with the looseness of the language in

> the document in which terms like (point, node) and (service provider,

> network provider, operator) are used interchangeably, even in

> contravention of how they are defined in the document.  This makes sections 2 and 3 somewhat confusing.

DC&YL>>  Good point. ACTN is actually solving network operator’s problem – as to how to control TE networks based on abstraction.

Since we introduced “operator” and “operations” in Introduction we’d like to change “network provider” to “network operator”. Whenever “operator” is mentioned, we meant “network operator” that own network infrastructure.

> Page 12, Section 3.1, 1st sentence: Wait, 2.2.2 says that VNS are

> delivered by the service providers, not network providers.  Yes, SPs

> can also be customers of infrastructure-only network providers (2.2.2,

> para 2), but this muddles the picture.  If CNCs are Service Provider

> devices (functions), then I withdraw the comment, but the naming (CNC)

> doesn't make it obvious that these are part of an SP.  The model given in Figure 1 and Section 2 strikes again.

DC&YL>>  CNC can be a direct customer’s control function or Service provider’s portal functions. To make it clear, we would reword the last sentence in Section 3.1:

OLD

For example, the CNC may in fact be a controller or part of a controller in the customer's domain, or the CNC functionality could also be implemented as part of a provisioning portal.

NEW

For example, the CNC may in fact be a controller or part of a controller in the customer's domain, or the CNC functionality could also be implemented as part of a service provider’s portal.

That said, we will change in Figure 2 from "network provider" to "network operator." MDSC is owned by the network operator.  We would also delete “business” from Figure 2.

We will add a sentence in Section 2.2.2 where service provider is explained for clarification:  "In some cases, service provider is also a network operator when it owns network infrastructure on which service is provided."

> Nits/editorial comments:

DC&YL>> We accept all your comments; please see some actions we have taken for some comments.

> Expand acronyms on initial use, particularly if the are not marked as

> common in the RFC Editor's list:

> https://www.rfc-editor.org/materials/abbrev.expansion.txt.

DC& YL>> Thanks for pointing this out: We expanded the following acronyms on initial use:

MPLS, OTN, WDM, YANG, WSON, SLA. Is there anything we might have missed?

> Change "multi domain" to "multidomain" (or "multi-domain").  Make a

> similar change for "inter domain".

DC& YL>> We would change to multi-domain/ inter-domain

> Page 5, Section 2.1, 1st sentence: append a blank line after this

> sentence to separate it from the following bullet item.

> Page 6, 1st partial paragraph, 1st partial sentence: make the last use

> of "network" plural.

> Page 6, 3rd bullet item: isn't this redundant since the 2nd bullet

> item essential defines it as well, especially with the reference to

> RFC 7926 [section 1.1.9]?

DC& YL>> Agree. Deleted.

> Page 11, 1st bullet item: this is basically a description of the MDSC.

> You manage to make a forward reference to PNC here.  Why not just drop

> MDSC in there as well?

DC& YL>> OK. We added: “from the Multi-Domain Service Coordinator (MDSC)” before “to the PNC”.

> Page 11, last bullet item: change "South Bound" to "Southbound", as

> used later in the document.

> Page 20, 1st sentence:  It might be reasonable to change "modes" to "types"

> to match the usage in the following two bullet items.

> Page 20, 1st bullet item: append a comma after "topology" and delete

> the second occurrence of "type".

> Page 25, Figure 10: explain what the line thicknesses mean.  It's

> almost certainly not what was meant in Figure 9.

DC& YL>> Do you mean ====? If so, we actually have the following text in which to say ===== is meant virtual link.

As shown in Figure 10, a customer asks for end-to-end connectivity between CE A and CE B, a virtual network. The customer's CNC makes a request to Provider 1's MDSC.  The MDSC works out which network resources need to be configured and sends instructions to the appropriate PNCs.  However, the link between Q and R is a virtual link supplied by Provider 2: Provider 1 is a customer of Provider 2.

> Page 26, 1st sentence after Table 1: what kind of provider is being

> discussed here, network or service?  Does it matter?  Does the

> separation of such in the model matter?  (See Minor Issues.)

DC& YL>> We will change to Operator (this is Network Operator).

> Page 27, section 6.1, 1st paragraph, 1st sentence: append a comma

> after "APs".

> Page 28, Table 4: It's not really clear to me how AP3 ends up with 40

> Gbps bandwidth.  It seems like you might be reusing assumptions from

> the previous example, but you should really set up the multi-homing

> example more clearly.

> In the previous example, AP2 was in a different domain, so it's not

> apparent why it would have 40 Gbps in this example.

DC& YL>. This is just an example. We change to 50 Gbps.

---

From: Peter Yee <[email-masked]>
Date: Thu, 10 May 2018 02:40:08 -0700

Young and Daniele,

Thanks for addressing my comments.  My apologies for not responding earlier – I’m on the road at the moment.  I’ve made specific responses below prefaced by PEY>.

                                Kind regards,

                                -Peter

On 5/4/18, 8:07 AM, "Leeyoung" <[email-masked]> wrote:

Hi Peter,

Best regards,

Young and Daniele

OLD

NEW

PEY> Works for me.

PEY> I think that covers the ones I had initially marked during my review.  At some point, I just stopped marking them and added the general nit to the review.

DC& YL>> Agree. Deleted. 

PEY> Yes, I meant the ----- and ==== lines.  They were explicitly defined in Figure 9.  In Figure 10, one has to interpret the text above the figure and intuit the meaning of the line thicknesses (==== could be understood from the top part of the diagram, while ---- requires one to make (reasonable) assumptions based on the text).  If you labeled Figure 10 like you did Figure 9, I think it would make comprehension easier.

PEY> Yes, I understood it be an example.  I’m trying to eliminate ambiguity between the examples so that there’s less confusion when reading the document.  Your change addresses my issue just fine.

---

From: Leeyoung <[email-masked]>
Date: Thu, 10 May 2018 15:14:50 +0000

Hi Peter,

Thanks for your further comments. It looks like the only remaining issue is the following.

Our resolution is to add as you suggested labels to explain what ---- and ==== mean as below in Figure 10:

Where

      --- is a link

      === is a virtual link

With that change, please review the diff file attached and let us know if all your comments are incorporated in v14 (to be published after your approval).

Thanks & Best regards,
Young and Daniele

From: Peter Yee [mailto:[email-masked]]
Sent: Thursday, May 10, 2018 4:40 AM
To: Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Daniele Ceccarelli <[email-masked]>
Subject: Re: Genart last call review of draft-ietf-teas-actn-framework-13

Young and Daniele,

                                Kind regards,
                                -Peter

On 5/4/18, 8:07 AM, "Leeyoung" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Peter,

Best regards,

Young and Daniele

> To: [email-masked]<mailto:[email-masked]>

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>

OLD

NEW

PEY> Works for me.

DC& YL>> Agree. Deleted.

---

From: Peter Yee <[email-masked]>
Date: Thu, 10 May 2018 08:40:26 -0700

Works well enough for me.  Thank you again for considering my input.

                                -Peter

On 5/10/18, 8:14 AM, "Leeyoung" <[email-masked]> wrote:

Hi Peter,

Where

      --- is a link

      === is a virtual link

Thanks & Best regards,

Young and Daniele

Young and Daniele,

                                Kind regards,

                                -Peter

Hi Peter,

Best regards,

Young and Daniele

OLD

NEW

PEY> Works for me.

DC& YL>> Agree. Deleted.

---

From: Leeyoung <[email-masked]>
Date: Thu, 10 May 2018 18:33:59 +0000

Hi Peter,

Thanks for your quick reply and approval of the changes.

Best regards,
Young and Daniele

Sent: Thursday, May 10, 2018 10:40 AM

                                -Peter

On 5/10/18, 8:14 AM, "Leeyoung" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Peter,

Where

      --- is a link

      === is a virtual link

Thanks & Best regards,
Young and Daniele

From: Peter Yee [mailto:[email-masked]]
Sent: Thursday, May 10, 2018 4:40 AM
To: Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>
Subject: Re: Genart last call review of draft-ietf-teas-actn-framework-13

Young and Daniele,

                                Kind regards,
                                -Peter

Hi Peter,

Best regards,

Young and Daniele

OLD

NEW

PEY> Works for me.

DC& YL>> Agree. Deleted.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 24 May 2018 09:17:40 -0400

Peter, thanks for your reviews of this document. Authors, thanks for your responses. I have entered a No Objection ballot.

Alissa

> On May 10, 2018, at 11:40 AM, Peter Yee <[email-masked]> wrote:
> 
> On 5/10/18, 8:14 AM, "Leeyoung" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Peter,
>  
> On 5/4/18, 8:07 AM, "Leeyoung" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Peter, <>
>  
> > From: Peter Yee [mailto:[email-masked] <mailto:[email-masked]>]
> > To: [email-masked] <mailto:[email-masked]>
> > Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> > [email-masked] <mailto:[email-masked]>
> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
> > 
> > https://www.rfc-editor.org/materials/abbrev.expansion.txt <https://www.rfc-editor.org/materials/abbrev.expansion.txt>.
>  
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art