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

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 14 Jul 2016 18:42:24 +0000

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.

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?

Thanks

Michael

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 15 Jul 2016 09:42:57 +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:[email-masked]] 
Sent: 2016年7月15日 2:42
To: [email-masked]
Cc: [email-masked]
Subject: Identifiers in draft-zhang-teas-transport-service-model 

Hi all,

<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.";
     }

    typedef svc-id {
        type string;
        description

<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

---

From: Anurag Sharma <[email-masked]>
Date: Sat, 16 Jul 2016 00:04:12 +0000

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) <[email-masked]> wrote:
> 
> Hi, Michael, all,
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "Xufeng Liu" <[email-masked]>
Date: Sun, 17 Jul 2016 17:07:31 -0400

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

> From: Teas [mailto:[email-masked]] On Behalf Of Anurag Sharma	
> Sent: Friday, July 15, 2016 8:04 PM
> To: Zhangxian (Xian) <[email-masked]>; Scharf, Michael (Nokia - DE)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]
> 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.
> 
> > 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 {
> > 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.
> >
> > <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

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 18 Jul 2016 18:04:21 +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.

> - 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

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

> From: Xufeng Liu [mailto:[email-masked]]
> Sent: Sunday, July 17, 2016 11:08 PM
> To: 'Anurag Sharma'; 'Zhangxian (Xian)'; Scharf, Michael (Nokia - DE)
> 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.
> 
> - The model is mostly for machine-to-machine interface. Client software
> can do the mapping if user friendly formats are needed.
> > 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)
> <[email-masked]>
> > wrote:
> > >
> > > Hi, Michael, all,
> > >
> > >    Thank you for taking this to seek wider opinions. Please first
> see my reply
> > inline:
> > >
> > > 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
> > > Is there any particular reason why IDs would have to be uint32 in a
> transport
> > service model context?
> > >

---

From: "Xufeng Liu" <[email-masked]>
Date: Mon, 18 Jul 2016 17:43:42 -0400

Hi Michael,

I think that your comments are about the service model, but I was replying to the comments from Anurag about the te-topology model, (not to your comments). 

Regards,

- Xufeng

> Sent: Monday, July 18, 2016 2:04 PM
> To: Xufeng Liu <[email-masked]>; 'Anurag Sharma'
> <[email-masked]>; 'Zhangxian (Xian)' <[email-masked]>
> Subject: RE: [Teas] Identifiers in draft-zhang-teas-transport-service-model
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> > 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.
> >
> > - The model is mostly for machine-to-machine interface. Client
> > software can do the mapping if user friendly formats are needed.
> > > Thanks for raising the issue with how ids are modeled in various
> > > YANG
> > models. I
> > > 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
> > > Feedback was provided on the id to authors of YANG model in TEAS.
> > > The
> > reason
> > > https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-04 ),
> > > which
> > is defined
> > > as below:
> > > >
> > > >     typedef te-tp-id {
> > > >       type union {