Re: [Teas] Genart last call review of draft-ietf-teas-actn-framework-13

Leeyoung <leeyoung@huawei.com> Fri, 04 May 2018 15:08 UTC

Return-Path: <leeyoung@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E034012D86A; Fri, 4 May 2018 08:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.154
X-Spam-Level:
X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, LONGWORDS=2.035, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWxEuKaJ0v7R; Fri, 4 May 2018 08:08:01 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AAEE12D7F1; Fri, 4 May 2018 08:08:00 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C02C6EF5B5898; Fri, 4 May 2018 16:07:53 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 4 May 2018 16:07:53 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.34]) by SJCEML702-CHM.china.huawei.com ([169.254.4.62]) with mapi id 14.03.0382.000; Fri, 4 May 2018 08:07:45 -0700
From: Leeyoung <leeyoung@huawei.com>
To: Peter Yee <peter@akayla.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "draft-ietf-teas-actn-framework.all@ietf.org" <draft-ietf-teas-actn-framework.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "teas@ietf.org" <teas@ietf.org>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Leeyoung <leeyoung@huawei.com>
Thread-Topic: Genart last call review of draft-ietf-teas-actn-framework-13
Thread-Index: AQHT4dVsu3XUKeW1nEyEwfa/K0z6RaQfrQtw
Date: Fri, 04 May 2018 15:07:44 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173CFE8978@sjceml521-mbx.china.huawei.com>
References: <152523847796.10768.14445109392931041172@ietfa.amsl.com>
In-Reply-To: <152523847796.10768.14445109392931041172@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.220.133.108]
Content-Type: multipart/mixed; boundary="_004_7AEB3D6833318045B4AE71C2C87E8E173CFE8978sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/6zlRiHnWKwbCwKbAbXWHF6T5aHQ>
Subject: Re: [Teas] Genart last call review of draft-ietf-teas-actn-framework-13
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2018 15:08:12 -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:peter@akayla.com]

> Sent: mercoledì 2 maggio 2018 07:21

> To: gen-art@ietf.org

> Cc: draft-ietf-teas-actn-framework.all@ietf.org; ietf@ietf.org;

> teas@ietf.org

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

>

> 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

> 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.

>

> 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.



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?



>

> 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".



DC& YL>> We would change to multi-domain/ 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]?



DC& YL>> Agree. Deleted.

>

> 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?



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 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.



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.

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