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

Leeyoung <leeyoung@huawei.com> Tue, 01 May 2018 19:20 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 EC59412EA54; Tue, 1 May 2018 12:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 g--9RLVBib-K; Tue, 1 May 2018 12:20:30 -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 D84841243F3; Tue, 1 May 2018 12:20:29 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 467B745E4384F; Tue, 1 May 2018 20:20:25 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 1 May 2018 20:20:26 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.34]) by SJCEML701-CHM.china.huawei.com ([169.254.3.144]) with mapi id 14.03.0382.000; Tue, 1 May 2018 12:20:17 -0700
From: Leeyoung <leeyoung@huawei.com>
To: Eric Gray <eric.gray@ericsson.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
CC: "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 WG <teas@ietf.org>, "Yemin (Amy)" <amy.yemin@huawei.com>
Thread-Topic: Rtgdir last call review of draft-ietf-teas-actn-info-model
Thread-Index: AdPd7Lqgg9fNbQqYTgGqURIPBCDASAAAZyHAAAgOEVAAzjLNsAABSnDwAAzNzZA=
Date: Tue, 01 May 2018 19:20:16 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173CFE4ED1@sjceml521-mbx.china.huawei.com>
References: <48E1A67CB9CA044EADFEAB87D814BFF64BA5577B@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF64BA557F4@eusaamb107.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E173CFDE208@sjceml521-mbs.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF64BA5BAD8@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF64BA5BAFF@eusaamb107.ericsson.se>
In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF64BA5BAFF@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.77]
Content-Type: multipart/mixed; boundary="_004_7AEB3D6833318045B4AE71C2C87E8E173CFE4ED1sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/k_miTTm49GsQgIlZXj7Z1kEjV7Y>
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: Tue, 01 May 2018 19:20:37 -0000

Hi Eric,

Thanks again for your good comments and quick reply to the last email. I think the only issue pending is:


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?



YL>>  Here we are talking about VN member level SRLG. If we have two VN members, say coming off from the same source to a two different destinations. If SRLG is set for this VN, it means VN member 1 from the source to destination 1 should be SRLG disjoint from VN member 2 from the source to destination 2. This concept of SRLG is a new concept on the VN member level.

Do we expect this to be clarified in later work – i.e. – is specifying this more precisely not in scope for this version, or is it supposed to be clear in (or from) this document?  If nothing else, there probably should be at least a hint at a use case example where this would be beneficial.

I gave a second thought and the SRLG discussion would be best to be deleted from Section 5.2. As you originally pointed out, it might be difficult to apply SRLG concept to VN or VN member level as SRLG has a physical implication. Since Section 5.2 has diversity as part of VN constraints, this would be sufficient to express how VN members are related to each other from the diversity/disjointness standpoint. So I removed the SRLG discussion from Section 5.2.

With that, the attached diff file compares the old version (07) and the new version (08). Please let us know if you are happy with version 08; else, please let us know your further comments.

Thanks & best regards,
Young (on behalf of other co-authors)

From: Eric Gray [mailto:eric.gray@ericsson.com]
Sent: Tuesday, May 01, 2018 8:05 AM
To: rtg-dir@ietf.org
Cc: Leeyoung <leeyoung@huawei.com>; draft-ietf-teas-actn-info-model.all@ietf.org; 'TEAS WG Chairs' <teas-chairs@ietf.org>; TEAS WG <teas@ietf.org>; Yemin (Amy) <amy.yemin@huawei.com>
Subject: FW: Rtgdir last call review of draft-ietf-teas-actn-info-model

Sorry for the SPAM, I had forgotten to check if RTG-DIR@ietf.org<mailto:RTG-DIR@ietf.org> was included as an addressee in the below response…

From: Eric Gray
Sent: Tuesday, May 01, 2018 9:01 AM
To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; draft-ietf-teas-actn-info-model.all@ietf.org<mailto:draft-ietf-teas-actn-info-model.all@ietf.org>; 'TEAS WG Chairs' <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; 'teas@ietf.org' <teas@ietf.org<mailto:teas@ietf.org>>
Cc: Yemin (Amy) <amy.yemin@huawei.com<mailto:amy.yemin@huawei.com>>
Subject: RE: Rtgdir last call review of draft-ietf-teas-actn-info-model

Young, et al,

You indicate that you will address the Nits, so (obviously) I am okay with that.  😊

One of my comments/questions came from a misunderstanding on my part – thanks for helping me to see it

Please see specific responses related to minor issues/questions below…

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Friday, April 27, 2018 7:56 AM
To: Eric Gray <eric.gray@ericsson.com<mailto:eric.gray@ericsson.com>>; draft-ietf-teas-actn-info-model.all@ietf.org<mailto:draft-ietf-teas-actn-info-model.all@ietf.org>; 'TEAS WG Chairs' <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; 'teas@ietf.org' <teas@ietf.org<mailto:teas@ietf.org>>
Cc: Yemin (Amy) <amy.yemin@huawei.com<mailto:amy.yemin@huawei.com>>
Subject: RE: Rtgdir last call review of draft-ietf-teas-actn-info-model
Importance: High


Hi Eric,



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



Please see inline for our response to your comment and let us know if our response is satisfactory to you.



Best regards,

Young (on behalf of co-authors)



-----Original Message-----
From: Eric Gray [mailto:eric.gray@ericsson.com]
Sent: Friday, April 27, 2018 1:12 AM
To: draft-ietf-teas-actn-info-model.all@ietf.org<mailto:draft-ietf-teas-actn-info-model.all@ietf.org>; 'TEAS WG Chairs' <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; 'teas@ietf.org' <teas@ietf.org<mailto:teas@ietf.org>>
Cc: Yemin (Amy) <amy.yemin@huawei.com<mailto:amy.yemin@huawei.com>>
Subject: RE: Rtgdir last call review of draft-ietf-teas-actn-info-model



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



YL>> We don’t necessarily assume the VNs/TE Tunnels are bi-directional. It can be uni-directional. As you pointed out, it will be helpful to explicitly specify directionality. How about in Section 5.2, we can add <VN directionality> in describing <VN Service Characteristics>.



<VN Service Characteristics> ::= <VN Connectivity Type>



                                   <VN Directionality>



                                    (<VN Traffic Matrix>...)



                                    <VN Survivability>

Okay.



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.



YL>> Agree. Will edit per your suggestion – delete “At the minimum” in both places.

Okay.



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.



YL>> Yes. Agree. Will add a new paragraph as follows:



   VN Modify, depending of the type of VN instantiated, can be an

   modification of the characteristics of VN members (edge-to-edge links) in case of VN type 1, or

   an modification of an existing virtual topology (e.g., adding/deleting virtual nodes/links) in case of VN type 2.

Great!



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.



YL>>  Agree with the NITs and the need for clarification statement.



OLD:

VN Query refers to inquiry pertaining to the VN that has been already instantiated. VN Query fulfills a pull model and permit to get topology view. VN Query Reply refers to the reply in response to VN Query.



NEW:



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.  VN Query Reply refers to the reply in response to VN Query. The topology view returned by VN Query Reply would be consistent with the topology type instantiated for any specific VN.

Great!





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.



YL>> Correct. TE actions should support at the MPI based on the types of topology defined at the CMI. I will add the following sentence as the second paragraph of Section 4:



NEW: The TE action primitives defined in this section should be supported at the MPI consistently with the type of topology defined at the CMI.

Great!





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?



YL>>  Here we are talking about VN member level SRLG. If we have two VN members, say coming off from the same source to a two different destinations. If SRLG is set for this VN, it means VN member 1 from the source to destination 1 should be SRLG disjoint from VN member 2 from the source to destination 2. This concept of SRLG is a new concept on the VN member level.

Do we expect this to be clarified in later work – i.e. – is specifying this more precisely not in scope for this version, or is it supposed to be clear in (or from) this document?  If nothing else, there probably should be at least a hint at a use case example where this would be beneficial.



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



YL>> Actually we have used VN member is equivalent to an end-to-end tunnel (CE-CE) from a customer standpoint.  What do you have in mind when you used the term “VN member pair”?

Sorry, I had missed something.  I had the (mistaken) idea that a “member” was an endpoint (CE), rather than a specific (CE-CE) tunnel.  On re-reading the draft, it is clear that you have defined VN member to be equivalent to end-to-end link.



I withdraw the comment.



NITs:

===

--- [SNIP] ---



--

Eric