[Teas] Re: [CCAMP]Missing switching-types for WSON and flexi-grid: WG LC comment for RFC 8776-bis or RFC 9093-bis

[Italo Busi <[e-mail]>]

Hi Julien,

I agree with you that LSC would have been better be defined in RFC9093 rather than in RFC8776 but it is not too late to change this

I do not see too much technical differences between the two options since YANG identities can be defined anywhere but I am a bit worried by the process-related issue if TE Types needs to be updated any time a new technology-specific switching type or LSP encoding type is defined

However, without guidelines, there is a risk to have duplicated definitions e.g., when TE types is updated by someone who is not aware of derived identities already being defined in other technology-specific model

I have checked whether RFC8776-bis provides some guidelines but actually it does not:

   lsp-encoding-types: A base YANG identity for supported LSP encoding
      types as defined in [RFC3471].

   <…>

   switching-capabilities:  A base YANG identity for supported interface
      switching capabilities as defined in [RFC3471].

The current text is also not fully accurate since RFC8876 defines also LSP encoding types and switching capabilities defined in other RFCs so we better take the opportunity to fix also this text

Option 1: if the decision is to define all the standardized LSP encodings and SCs identities in TE Types, the text can be updated as follow:

   lsp-encoding-types: A base YANG identity for supported LSP encoding
      types as defined in [RFC3471], [RFC4328] and [RFC6004].

      Other standardized LSP encoding types can be defined in future
      updates of the “ieft-te-types” YANG data model.

   <…>

   switching-capabilities:  A base YANG identity for supported interface
      switching capabilities as defined in [RFC3471], [RFC6002],
      [RFC6004], [RFC7138], [RFC7688] and [RFC8363].

      Other standardized interface switching capabilities can be
      defined in future updates of the “ieft-te-types” YANG data
      model.

Option 2: if the decision is to define WSON-LSC and Flexi-Grid-LSC identities in L0 Types, the text can be updated as follow, to give guidance on where future technology-specific identities should be defined:

   lsp-encoding-types: A base YANG identity for supported LSP encoding
      types as defined in [RFC3471], [RFC4328] and [RFC6004].

      Additional technology-specific LSP encoding types can be defined
      in other technology-specific models.

   <…>

   switching-capabilities:  A base YANG identity for supported interface
      switching capabilities as defined in [RFC3471], [RFC6002],
      [RFC6004] and [RFC7138].

      Additional technology-specific interface switching capabilities
      can be defined in other technology-specific models.

Opinions?

I have also noted that RFC7074 provide some further clarification about the definition of LSP encoding types and switching capability and deprecates PSC-2, PSC-3 and PSC-4, thus providing the rationale for not defining corresponding identities in TE-Types

I am wondering whether it is worthwhile adding also RFC7074 to the list of RFCs referenced for the definitions of the lsp-encoding-types and switching-capabilities identities?

Opinions?

Italo

From: [e-mail] <[e-mail]>
Sent: giovedì 14 novembre 2024 21:11
To: Italo Busi <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [CCAMP]Missing switching-types for WSON and flexi-grid: WG LC comment for RFC 8776-bis or RFC 9093-bis

Hi Italo,

I we were adding them from scratch, I'd fully agree to prefer L0 Types... However, I'm not sure it's a good idea to have LSC in one document and WSON-LSC/Flexi-Grid-LSC in a different one.

Thanks,

Julien

On 09/11/2024 12:18:25 Italo Busi <Italo.Busi=[e-mail]><mailto:Italo.Busi=[e-mail]> wrote:

I have recently noted that there are no standardized YANG identities that could be used to represent the WSON-LSC, defined in RFC 7688, and flexi-grid LSC, defined in RFC 8363

I am not sure whether these identities are better defined in TE Types (RFC 8776-bis) or Layer0 Types (RFC 9093-bis) YANG models but since both drafts are in WG LC we can fix in either was this gap

My personal preference is to add them to RFC 9093-bis in order to avoid the need to update TE Types any time a new technology-specific switching type or LSP encoding type is defined

What do you think?

Italo