Re: [Teas] IANA managed modules for TE object types

[Italo Busi <[e-mail]>]

Hi Tarek, all,

If the intention is to define identities or enumerations that fully matches the content of a protocol registry maintained by IANA, I agree that the definition of IANA-maintained modules is the best solution since this approach simplifies the maintenance of the YANG module as well as ensures alignment between the protocol registry and the YANG module

However, I am not sure this was the original intention ...

For the error reasons, there are some error reasons which are:

  1.  applicable only to the ietf-te YANG model and not to PCEP (e.g., path-computation-error-no-topology);
  2.  technology-specific (e.g., No RWA constraints met);
  3.  match more than one PCEP numbers in order to hide the details of the underlay PCE architecture (e.g.,  path-computation-error-no-dependent-server)

Case a) can be supported also defining identities for the PCEP registry in an IANA-maintained module and the additional identities applicable only to ietf-te YANG model either within the ietf-te or within the ietf-te-types YANG modules

Case c) can be handled like case a) although not using an IANA-maintained module would allow defining a hierarchy between the generalized and the specific error reasons (not sure this is really needed and this has not been done in current ietf-te YANG model)

For case b) it would not be possible defining the technology-specific identifies within technology-specific modules: the IANA-maintained module will contain both common and technology-specific error reasons

I have checked on github the notes from previous discussions and noticed that at the beginning we were planning to do some cherry-picking from the IANA registry but at the end all errors have been added (not clear why):

https://github.com/tsaad-dev/te/issues/54

It seems that this change has also created a duplication between the path-computation-error-pce-unavailable and the path-computation-error-no-server identities

My suggestion is to review and clean-up the current definitions of the error reasons and to decide whether it is desired or not to be fully aligned with the PCEP numbers assigned by IANA. Should we re-open issue #54 in github or open a new issue?

For the association types, it seems that the identities defined in RFC 8776 are aligned with the GMPLS association registry (https://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xhtml#gmpls-sig-parameters-9) rather than with the PCEP association registry (https://www.iana.org/assignments/pcep/pcep.xhtml#association-type-field), with the only exceptions of the "Bypass Summary FRR Ready Association (B-SFRR-Ready)" and "Bypass Summary FRR Active Association (B-SFRR-Active)" values which have been assigned by IANA after RFC 8776 (in RFC 8796) and which also looks like technology-specific

However, the ietf-te YANG module extends the association types defined in RFC 8776 with the association-type-diversity defined in RFC 8880 and which seems registered by IANA within the PCEP association registry ...

Also here my suggestion is to review and clean-up the current definitions of the error reasons and to decide whether it is desired or not to be fully aligned with the PCEP and/or GMPLS numbers assigned by IANA

My 2 cents for further consideration

Italo

From: Tarek Saad <[e-mail]>
Sent: venerdì 13 maggio 2022 19:59
To: [e-mail]
Cc: Adrian Farrel <[e-mail]>
Subject: [Teas] IANA managed modules for TE object types

Hi WG,

During the review of draft-ietf-teas-yang-te, Adrian raised an important point about IANA managing some YANG module that models specific TE types. For example, ID draft-ietf-teas-yang-te was modelling 'no-path' some error reasons as listed in https://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector-tlv or association types as defined in  https://www.iana.org/assignments/pcep/pcep.xhtml#association-type-field.

There are obvious advantages to having such YANG types in separate modules and letting IANA manage them. For example,

  1.  Other TE modules can freely import such types modules (without needing to import feature modules such as one defined in draft-ietf-teas-yang-te).
  2.  Allowing IANA to manage these modules may facilitate extensions in the future (IANA can automatically ensure that IANA types and YANG module are in sync).

The authors discussed this suggestion and would like to proceed with it, but want to make sure this is the recommended approach for other types that are managed by IANA and may be modelled in YANG in the future.

Regards,
Tarek (for the co-authors of draft-ietf-teas-yang-te)