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