Re: [Teas] Rtgdir last call review of draft-ietf-teas-actn-info-model

Eric Gray <eric.gray@ericsson.com> Fri, 27 April 2018 06:12 UTC

Return-Path: <eric.gray@ericsson.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 7A87212D957 for <teas@ietfa.amsl.com>; Thu, 26 Apr 2018 23:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 vzColNXHIXN3 for <teas@ietfa.amsl.com>; Thu, 26 Apr 2018 23:12:25 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 9789712D953 for <teas@ietf.org>; Thu, 26 Apr 2018 23:12:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1524809544; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Cw0tH3w2u7U1oi5eLlEAjIzMrQ3V28p25hg0J/WjF6M=; b=dWR8BLzjhucYTWVhUJMNMgLJME8CuMJvCxQjCAF3K0n7pyaj4Gfi20mYCkiyDygf jjPAF2h0jlni4SuqyrE3jx7tufE4iAB9QVK2UGbR9pRk3ZyuR7+f15dzQN5lcH12 4OwDfzCzdEKY3n5LC+oor2hxkIc11EA/+NpLags9yvU=;
X-AuditID: c6180641-1ebff70000003b41-24-5ae2bf483308
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id B7.29.15169.84FB2EA5; Fri, 27 Apr 2018 08:12:24 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0382.000; Fri, 27 Apr 2018 02:12:24 -0400
From: Eric Gray <eric.gray@ericsson.com>
To: "draft-ietf-teas-actn-info-model.all@ietf.org" <draft-ietf-teas-actn-info-model.all@ietf.org>, 'TEAS WG Chairs' <teas-chairs@ietf.org>, "'teas@ietf.org'" <teas@ietf.org>
CC: 'Min Ye' <amy.yemin@huawei.com>
Thread-Topic: Rtgdir last call review of draft-ietf-teas-actn-info-model
Thread-Index: AdPd7Lqgg9fNbQqYTgGqURIPBCDASAAAZyHA
Date: Fri, 27 Apr 2018 06:12:22 +0000
Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF64BA557F4@eusaamb107.ericsson.se>
References: <48E1A67CB9CA044EADFEAB87D814BFF64BA5577B@eusaamb107.ericsson.se>
In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF64BA5577B@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXSPt67H/kdRBgsPm1ls7tjAZtH37T2r RdPcXUwWrT92sDiweLQcecvqsWTJT6YApigum5TUnMyy1CJ9uwSujKVvFrEX3DGv+NWynbWB cYlZFyMnh4SAicSraa/Yuhi5OIQEjjJKHP48iwnCWc4oceH3LRaQKjYBDYljd9YygiREBDYy SpyfPYUZJMEsoCxxd/N0JhBbWMBdYt6WM0BFHEBFHhKTd4iChEUEjCS27zjMDmKzCKhKXOzb zgpi8wr4Svy5ehysVQjIPnbgM9hITgE/iXk3F4LZjAJiEt9PrWGCWCUucevJfCaIqwUkluw5 zwxhi0q8fPyPFcJWlNjXP50d5ARmAU2J9bv0IVoVJaZ0P2SHWCsocXLmE5YJjKKzkEydhdAx C0nHLCQdCxhZVjFylBYX5OSmGxluYgTGxzEJNscdjHt7PQ8xCnAwKvHwdmx+FCXEmlhWXJl7 iFGCg1lJhHfH7YdRQrwpiZVVqUX58UWlOanFhxilOViUxHnPefJGCQmkJ5akZqemFqQWwWSZ ODilGhhr/nKGduW2Llr2abPW0doD1xfHtmn1H7rDc/xPu3TN3g8rhYuXy10vfmDGyH6Nu0lP zITB8UVU2el5Hdbtf7ff2vv4nVFUZdrKTz55Uw99KD/50riledOUWv4N9ffOTTghtTzKfvES rmYH54ku1aWhZybkSFuHvn40k7/go+ks+aAgk21nl59SYinOSDTUYi4qTgQA8B2nNIsCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Fh17jpcUXim8DKreyvdjkHFIzw0>
Subject: Re: [Teas] Rtgdir last call review of draft-ietf-teas-actn-info-model
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, 27 Apr 2018 06:12:28 -0000

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 last call and IESG review. 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 Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-teas-actn-info-model
Reviewer: Eric Gray
Review Date: April 27, 2018
LC End Date: April 27, 2018
Intended Status: Informational

*Summary:*
Draft Status: Almost ready with minor issues and NITs.

Note: this is not a YANG technical review.

Minor Issues / Questions:
====================
As a general minor question, when instantiating  a topology including only member information, is it assumed that - given a list of members - each member is bi-directionally connected to every other member, are end-to-end member connections pairwise (e.g. - allowing setup of a hub and spoke topology), or is it necessary/possible to define directionality (e.g. - allowing setup of a distribution tree)? 

Note: This should probably be explicitly stated, though section 5.3 seems to imply that both connectivity and directionality are supported (at least the way I read it).

Section 3, top of page 6: while this draft is intended to be informational and does not refer to RFC 2119, the wording "at a minimum" and "should be supported" is inconsistent (or arguably redundant).  I recommend omitting the 1st part ("At a minimum,") making the sentence read instead "The following VN Action ..."
A similar issue applies to the 2nd paragraph in section 4.

Section 3.2, VN Modify: It looks as if this section needs to include text similar to that in section 3.4, given the possible topology types described in section 3.1.  In addition, you may want to restrict what is allowed in a VN Modify to actions consistent with the VN topology type previously instantiated.

Section 3.6, VN Query: In addition to certain NITs, this section should make it clear that the "topology view" returned by VN Query would be consistent with the topology type instantiated for any specific VN.

Section 4, Traffic Engineering (TE) primitives: Does it make sense that the TE actions should be supported at the MPI consistently with the type of topology defined at the CMI, or are they independent?  Section 4.4 seems to imply that consistency is expected.

Section 5.2, VN Service Characteristics: in the shared risk discussion (towards the top of page 12), it is difficult to indicate (with any accuracy) what the shared risks are for a topology type consisting of just a list of members.  Is this limited to topologies of the type that includes (virtual) link and node information?

Section 5.4, 1st sentence: VN Member is not equal to end-to-end tunnel.  I suspect you mean "VN member pair."


NITs:
===
In several sections, the use of capitalization is inconsistent in the section titles that include the word "primitives."  See sections 3, 4, 7 and 8 in the ToC and in the text.

In the paragraph under Figure 1, "there of" should be one word ("thereof").

Same paragraph, "MDSC to MSDC" should be "MDSC to MDSC" (referring to a hierarchy of MDSCs).

Section 2, 1st line: "provides ACTN common ..." should be "provides an ACTN common ..."

Section 3.6, 1st paragraph: there are minor grammar issues with the entire paragraph.  I suggest rewording along lines as follows (minimal change):

"VN Query refers to an inquiry pertaining to a VN that has already been instantiated.  VN Query fulfills a pull model that permits getting a topology view."  

Note: see related minor issue above.

Section 4, 1st line: "... list of main ..." should be "... list of the main ..."

Section 5.2, toward the middle of page 11: "... for the required the service ..." should be "... for the required service ..."  In the very next sentence, "constrains" should be "constraints" and "VN Constrains" should be "VN Constraints."

Section 5.3, bottom of page 13: "Access point identifier ..." should be "Access Point Identifier ..."
In the next sentence, "creation" should probably be "instantiation"

Section 5.3, top of page 14: "... his own ..." should be "... their own ..."

Section 5.6, last sentence in 1st paragraph: should be reworded as:

"... is composed of virtual nodes and virtual links." ("is comprised of" is an incorrect, idiomatic, usage, and "virtual" and "and" need to be shifted around).

Section 5.7.1, 1st sentence: "from higher controller" should "from a higher controller."

Toward bottom of page 18: "Set Priority ... priority to taking ..." should be "Set Priority ... priority for taking ..."

Section 9, 2nd sentence in 1st paragraph: "confidentially" should be "confidentiality"
Same section, 2nd paragraph "... regardless these ..." should be "... regardless of whether these ..."

--
Eric