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

[Anurag Sharma <[e-mail]>]

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) <[e-mail]> 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:[e-mail]] 
> Sent: 2016年7月15日 2:42
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas