Label encoding w/ branching?

ju7ien commented 3 years ago

Label encoding has 2 sub-cases, distinguishing between single and super channels. Any reason not to encode the former as a "single-carrier super channel"? Several advantages:

removes the branching level,
every case is encoded as a subcarrier-flexi-n dictionnary (with a single entry for single channel), simplifying implementations,
increases the consistency with draft-ietf-ccamp-optical-impairment-topology-yang, which reuses the OTSi-Group containing one or more OTSi's, as defined by the ITU-T.

That would end up into something like:

+--:(flexi-grid)
   +--rw rw subcarrier-flexi-n* [flexi-n]
      +--rw flexi-n    l0-types:flexi-n
      +--rw flexi-m?   l0-types:flexi-m

danielkinguk commented 3 years ago

This would be more efficient, but a few impacts with this change, including impact with with layer-0-types and optical-impairment-topology models.

No strong opinion on the change at this point.

agva123 commented 3 years ago

I do not have a strong opinion on the branching, either.

One may think of this issue from a different perspective, that the model actually provides two mechanisms for single channel specification, one way by directly using the leaves under the "single" branch, while the other way by using the list under the "super" branch. Note that a) the branching names are not in an xpath instance, nevertheless, and b) l0-types is already out as RFC, so the groupings cannot be changed in there.

I recalled that the branching between (single, super) channels was originally intended to facilitate the specification of single channel without always needing to point to a list.

E.g. an xpath could be constructed as follows if using the "single" branch: ..../tet:te-label/l0-types:flexi-n, .../tet:te-label/l0-types:flexi-m,

or, in another way by using the "super" branch: ..../tet:te-label/l0-types:subcarrier-flexi-n[flexi-n=123]/flexi-n, ..../tet:te-label/l0-types:subcarrier-flexi-n[flexi-n=123]/flexi-m

italobusi commented 3 years ago

The flexi-grid-label-hop grouping has been defined in RFC9093 (layer0-types) but, up to now, it is not used by any published RFC.

I am not sure this is sufficient not to apply the requirements in section 10 of RFC7950 when revising layer0-types.

An alternative option could be to define a new grouping and either do not modify the flexi-grid-label-hop grouping or deprecate it.

The WSON topology YANG model has been already published as RFC9093, Keeping the choice would make the flexi-grid models more consistent with the WSON models:

       +--:(wson)
          +--ro (grid-type)?
             +--:(dwdm)
             |  +--ro (single-or-super-channel)?
             |     +--:(single)
             |     |  +--ro dwdm-n?              l0-types:dwdm-n
             |     +--:(super)
             |        +--ro subcarrier-dwdm-n*   l0-types:dwdm-n
             +--:(cwdm)
                +--ro cwdm-n?                    l0-types:cwdm-n

As pointed out by Aihua, neither in WSON nor in flexi-grid there is any min-element statement that precludes using the (super) case for a single channel with a list of one element.

An alternative option could be not to change the YANG model but to clarify that the (super) case can be used also for single channel e.g. in the layer0-types-ext.

ju7ien commented 3 years ago

As pointed out by Aihua, neither in WSON nor in flexi-grid there is any min-element statement that precludes using the (super) case for a single channel with a list of one element. An alternative option could be not to change the YANG model but to clarify that the (super) case can be used also for single channel e.g. in the layer0-types-ext.

I'd prefer the opposite: if the branching remains, then there should be a unique way to describe a single-channel label (i.e., prevent the use of super in case of single n). Otherwise, interoperability issues can be expected...

danielkinguk commented 2 years ago

This will impact layer-0, and the backwards compatibility will need to be considered.

sergiobelotti commented 1 year ago

This would be more efficient, but a few impacts with this change, including impact with with layer-0-types and optical-impairment-topology models.

No strong opinion on the change at this point.

I do not see impact at the moment in optical-impairment-topology: the model is not using "flexi-grid-label-hop" grouping where this branching is defined.

sergiobelotti commented 1 year ago

As pointed out by Aihua, neither in WSON nor in flexi-grid there is any min-element statement that precludes using the (super) case for a single channel with a list of one element. An alternative option could be not to change the YANG model but to clarify that the (super) case can be used also for single channel e.g. in the layer0-types-ext.

I'd prefer the opposite: if the branching remains, then there should be a unique way to describe a single-channel label (i.e., prevent the use of super in case of single n). Otherwise, interoperability issues can be expected...

let's do not change the model , as proposed by Italo and to agree a text to add in the draft. What about : "Even if ,in the grouping flexi-grid-label-hop, in the branching the (super) case could ,synthetically, be used also for single channel , the suggestion is to use a unique way to describe a single-channel label to avoid interoperability issues in case for single channel you would use the "supe" option in the branch."

sergiobelotti commented 1 year ago

weekly call 05-16-23

Decision: We can suggest to deprecate the choice in the YANG code of "flexi-grid-label-hop" grouping and use instead a single list. This update impacting the syntanx but not semantically the structure is avoiding problem for interoperability . We need to share the update in the mailing list.

OLD

+--:(flexi-grid)
   +--rw (single-or-super-channel)?
      +--:(single)
      |  +--rw flexi-n?              l0-types:flexi-n
      |  +--rw flexi-m?              l0-types:flexi-m
      +--:(super)
         +--rw subcarrier-flexi-n* [flexi-n]
            +--rw flexi-n    l0-types:flexi-n
            +--rw flexi-m?   l0-types:flexi-m

NEW

+--:(flexi-grid)
   x--rw (single-or-super-channel)?
   |  x--:(single)
   |  |  x--rw flexi-n?              l0-types:flexi-n
   |  |  x--rw flexi-m?              l0-types:flexi-m
   |  x--:(super)
   |     x--rw subcarrier-flexi-n* [flexi-n]
   |        x--rw flexi-n    l0-types:flexi-n
   |        x--rw flexi-m?   l0-types:flexi-m
   +--rw tbd* [flexi-n]
      +--rw flexi-n    l0-types:flexi-n
      +--rw flexi-m?   l0-types:flexi-m

sergiobelotti commented 1 year ago

Call on 09-26-23: Esther/Aihua: suggested to add "min-elements" statement to the list under the "super" branch, imposing a constraints that avoids to use the list for single element (then for single-channel). Post-meeting notes: Sergio: to do that a new grouping , a copy of "flex-grid-label-hop" has to be defined since per backward compatibility we cannot modify the original grouping (defined in RFC9093).

grouping tbd {
    description
      "Generic label-hop information for flexi-grid";
    choice single-or-super-channel {
      description
        "single or super channel";
      case single {
        uses flexi-grid-frequency-slot;
      }
      case super {
        list subcarrier-flexi-n {
          key "flexi-n";
          uses flexi-grid-frequency-slot;
          min-elements 2;
          description
            "List of subcarrier channels for flexi-grid super
             channel.";
        }
      }
    }
    reference
      "RFC 7698: Framework and Requirements for GMPLS-Based Control
       of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM)
       Networks";
  }

ietf-ccamp-wg / ietf-ccamp-layer0-types-ext-RFC9093-bis

Label encoding w/ branching? #33