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

"Zhangxian (Xian)" <> Fri, 15 July 2016 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A922912DC0A; Fri, 15 Jul 2016 02:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.508
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EdxSIVrKJAPy; Fri, 15 Jul 2016 02:43:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C506412DC06; Fri, 15 Jul 2016 02:43:15 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CNS51362; Fri, 15 Jul 2016 09:43:13 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 15 Jul 2016 10:43:11 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Fri, 15 Jul 2016 17:42:57 +0800
From: "Zhangxian (Xian)" <>
To: "Scharf, Michael (Nokia - DE)" <>, "" <>
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: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
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=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6a34ae12d68bd7057a897e8b1e8330b6
Archived-At: <>
Cc: "" <>
Subject: Re: [Teas] Identifiers in draft-zhang-teas-transport-service-model
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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) [] 
Sent: 2016年7月15日 2:42
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, ( ),  which is defined as below:

     typedef te-tp-id {
       type union {
         type uint32;          // Unnumbered
         type inet:ip-address; // IPv4 or IPv6 address
         "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;
         "Defining a type of service component

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.