Re: [Teas] Identifiers in draft-zhang-teas-transport-service-model

"Zhangxian (Xian)" <zhang.xian@huawei.com> Fri, 15 July 2016 09:43 UTC

Return-Path: <zhang.xian@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 A922912DC0A; Fri, 15 Jul 2016 02:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Level:
X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 EdxSIVrKJAPy; Fri, 15 Jul 2016 02:43:18 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C506412DC06; Fri, 15 Jul 2016 02:43:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNS51362; Fri, 15 Jul 2016 09:43:13 +0000 (GMT)
Received: from SZXEMA415-HUB.china.huawei.com (10.82.72.33) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 15 Jul 2016 10:43:11 +0100
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.209]) by SZXEMA415-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0235.001; Fri, 15 Jul 2016 17:42:57 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Identifiers in draft-zhang-teas-transport-service-model
Thread-Index: AdHd/3YJplNRRE/bSOqEpubS5Z2jZwANWyxA
Date: Fri, 15 Jul 2016 09:42:57 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B7DF00E7F@SZXEMA512-MBS.china.huawei.com>
References: <655C07320163294895BBADA28372AF5D4891DCBC@FR712WXCHMBA15.zeu.alcatel-lucent.com>
In-Reply-To: <655C07320163294895BBADA28372AF5D4891DCBC@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5788B031.022A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.209, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6a34ae12d68bd7057a897e8b1e8330b6
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/9qml65OmWlF4OEF9ZjjiFwXM2yk>
Cc: "draft-zhang-teas-transport-service-model@ietf.org" <draft-zhang-teas-transport-service-model@ietf.org>
Subject: Re: [Teas] Identifiers in draft-zhang-teas-transport-service-model
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
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, 15 Jul 2016 09:43:21 -0000

Hi, Michael, all,

    Thank you for taking this to seek wider opinions. Please first see my reply inline:

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] 
Sent: 2016年7月15日 2:42
To: teas@ietf.org
Cc: draft-zhang-teas-transport-service-model@ietf.org
Subject: Identifiers in draft-zhang-teas-transport-service-model 

Hi all,

I have had some off-list discussions with the authors of draft-zhang-teas-transport-service-model. Regarding one specific point I look for further feedback on the list:

To me it seems a quite surprising design choice to model in a service model endpoints (tp-id) and service IDs (service-id) by an integer value (uint32). A more obvious choice to me would be e.g. a string.

<Xian>: For Service identifier, there is an uint32 for service-id, there is also a string for service-name. So if you like to use the string-name for differentiate your service, you can do that.  As for the service model endpoints, we are mainly bound by the termination points defined by ietf-te-topology.yang, (https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-04 ),  which is defined as below:

     typedef te-tp-id {
       type union {
         type uint32;          // Unnumbered
         type inet:ip-address; // IPv4 or IPv6 address
       }
       description
         "An identifier for a TE link endpoint on a node.
          This attribute is mapped to local or remote link identifier in
          RFC3630 and RFC5305.";
     }

This seems to be common practice in another service model of the IETF. See draft-ietf-l3sm-l3vpn-service-model-11:

    typedef svc-id {
        type string;
        description
         "Defining a type of service component
         identificators.";
    }

I think the IETF should try to align at least basic constructs in "service models" even if they apply to different technologies. Some communality at least regarding identifiers would be a good starting point, IMHO.

Is there any particular reason why IDs would have to be uint32 in a transport service model context?

<Xian>:  I understand your concern, but I think you already answered the question since it is as you said: " they apply to different technologies" and probably also on different interfaces. To give you another similar example: if you check the ietf-network.yang/ietf-network-topology.yang and ietf-te-topology.yang, where the later augments the former. They use different types of identifiers for identifying a network/topology, a node and a link and a termination point (uri. Vs. non-uri).  Having said all these, I am open and would also like to hear how others think about this. 

Cheers,
Xian

Thanks

Michael