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

"Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com> Mon, 18 July 2016 18:04 UTC

Return-Path: <michael.scharf@nokia.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 6BD9012DB3B; Mon, 18 Jul 2016 11:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 QVRS8h1TTBFn; Mon, 18 Jul 2016 11:04:28 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6EC1412D861; Mon, 18 Jul 2016 11:04:28 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 49DFE5C8E3AB4; Mon, 18 Jul 2016 18:04:23 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6II4Qkx007902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 18:04:26 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6II4JMk028678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jul 2016 20:04:25 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 18 Jul 2016 20:04:22 +0200
From: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>, 'Anurag Sharma' <AnSharma@infinera.com>, "'Zhangxian (Xian)'" <zhang.xian@huawei.com>
Thread-Topic: [Teas] Identifiers in draft-zhang-teas-transport-service-model
Thread-Index: AQHR3n1btOJjOu11TkCZ0pDJsZqTs6AaDKgAgALzTICAAXpisA==
Date: Mon, 18 Jul 2016 18:04:21 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48926C5B@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <655C07320163294895BBADA28372AF5D4891DCBC@FR712WXCHMBA15.zeu.alcatel-lucent.com> <C636AF2FA540124E9B9ACB5A6BECCE6B7DF00E7F@SZXEMA512-MBS.china.huawei.com> <A18E30EB-EC20-4EE1-A917-41E71904BE53@infinera.com> <002101d1e06f$3c4a77c0$b4df6740$@gmail.com>
In-Reply-To: <002101d1e06f$3c4a77c0$b4df6740$@gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/KPaaSYbHFdBu166khEGE3lvz4Uc>
Cc: "draft-zhang-teas-transport-service-model@ietf.org" <draft-zhang-teas-transport-service-model@ietf.org>, "teas@ietf.org" <teas@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: Mon, 18 Jul 2016 18:04:32 -0000

Hi all,

I guess the fundamental question is whether a "transport service model" would use network-internal identifiers to identify endpoints, or whether it would have to rely on identifiers that have to be mapped to external systems.

The term "service model" is not well-defined in the IETF but there is some positioning on this in draft-wu-opsawg-service-model-explained. Note that I have some concerns regarding this specific I-D. Yet, if the model in draft-zhang-teas-transport-service-model has the scope explained in draft-wu-opsawg-service-model-explained, the identifiers in the model will be customer-facing. Use of integers as unique customer-visible identifiers seems one option but it is not the only choice.

It the I-D draft-zhang-teas-transport-service-model should have a different focus than draft-wu-opsawg-service-model-explained then there is a terminology issue and probably an inconsistency between the two I-Ds that needs to be addressed.

Regarding the specific points:

> - Compatible to current implementations and RFCs.

I have already pointed out that the L3SM service model, which is a similar service model, is not consistent so the argument about compatibility with "RFCs" does not apply.

> - More efficient to implement (e.g. searching, sorting, and indexing).

At least in the environment I deal with this would not be any relevant concern as we are able to efficiently process values other than integers, including scalable searching, sorting, and indexing. We deal with systems that handle huge amounts of services.

> - Easier to advertise.

I cannot follow. The document talks about controller NBIs which typically have a JSON, XML, ... interface and in that case quite a number of different encodings can be advertised.

> - Easier to do automation (e.g. getting the next available value).

I cannot follow. Given services get added and deleted, the number space will have gaps if numerical values are picked. Renumbering will not be an option if external systems can see the ID.

> - The model is mostly for machine-to-machine interface. Client software
> can do the mapping if user friendly formats are needed.

Sure but this applies to many other encodings as well.

> - No need for parsing and conversion, and no ambiguity for
> interpretation.

And this also applies to other formats.

In summary, this selection of identifiers is a bad design choice that significantly limits the applicability of the model.

Thanks

Michael


> -----Original Message-----
> From: Xufeng Liu [mailto:xufeng.liu.ietf@gmail.com]
> Sent: Sunday, July 17, 2016 11:08 PM
> To: 'Anurag Sharma'; 'Zhangxian (Xian)'; Scharf, Michael (Nokia - DE)
> Cc: draft-zhang-teas-transport-service-model@ietf.org; teas@ietf.org
> Subject: RE: [Teas] Identifiers in draft-zhang-teas-transport-service-
> model
> 
> Hi Anurag,
> 
> Thanks for the comments. As we discussed, we are bringing this issue to
> the working group. We will discuss it during the TEAS session on
> Thursday.
> 
> As for TE nodes and links, the TE topology model provides both I2RS URI
> ID type and numerical ID type.
> 
> We actually also got some complaints about the I2RS URI ID type from
> some model implementers.
> 
> In our case, some of the reasons to use numerical ID type are:
> - Compatible to current implementations and RFCs.
> - More efficient to implement (e.g. searching, sorting, and indexing).
> - Easier to advertise.
> - Easier to do automation (e.g. getting the next available value).
> - The model is mostly for machine-to-machine interface. Client software
> can do the mapping if user friendly formats are needed.
> - No need for parsing and conversion, and no ambiguity for
> interpretation.
> 
> Thanks,
> 
> - Xufeng
> 
> > -----Original Message-----
> > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Anurag Sharma
> > Sent: Friday, July 15, 2016 8:04 PM
> > To: Zhangxian (Xian) <zhang.xian@huawei.com>; Scharf, Michael (Nokia
> - DE)
> > <michael.scharf@nokia.com>
> > Cc: draft-zhang-teas-transport-service-model@ietf.org; teas@ietf.org
> > Subject: Re: [Teas] Identifiers in draft-zhang-teas-transport-
> service-model
> >
> > Michael,
> >
> > Thanks for raising the issue with how ids are modeled in various YANG
> models. I
> > completely agree with you that there is a major disconnect between
> YANG
> > models in i2rs, teas, ccamp when it comes to modeling ids.
> Additionally, there is
> > major disconnect between IETF YANG models, and YANG models from other
> > SDOs (ids modeled as string) when it comes to modeling ids. The id
> issue came
> > up during our analysis of various YANG models for transport use
> cases. Sergio,
> > Xian, Oscar, and many other folks from IETF, ONF and MEF are part of
> the
> > analysis activity. In a network where there are YANG models from
> different
> > SDOs in the domain controller and the orchestrator, translation /
> mediation
> > between these models has issues when entity ids have different types
> (uint vs.
> > uuid/string).
> >
> > Feedback was provided on the id to authors of YANG model in TEAS. The
> reason
> > given for using uint was that GMPLS protocols on the devices use
> uint.
> > Alternative provided was to have another model that augments the TE
> YANG
> > models, and add string as id, which I think is not clean given the
> number of
> > augmentations you will need. We were also asked to raise the concern
> on the
> > teas mailing list. It’s good to see your comments in the same area.
> Maybe the
> > YANG model authors in TEAS can rethink how id are modeled.
> >
> > Xufeng, Pavan, can you please reconsider how ids are modeled in your
> YANG
> > model?
> >
> > Thanks,
> > Anurag
> >
> > > On Jul 15, 2016, at 2:42 AM, Zhangxian (Xian)
> <zhang.xian@huawei.com>
> > wrote:
> > >
> > > 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
> > > _______________________________________________
> > > Teas mailing list
> > > Teas@ietf.org
> > > https://www.ietf.org/mailman/listinfo/teas
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas