Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Continue the review of Photonic Model and other enhancements available in the pull request 524

Agreed Items & Priority

Discussion items

5 minsAdministrative

All



TAPI RIA 2.0 (ONF TAPI RIA):

  • Scheduled two additional, dedicated TAPI calls:
    • Mon 14-16 and Wed 13-15 CEsT

See TAPI Call-in Details and Notes for the details.


TAPI weeky call - canceled (Andrea Mazzini not available)

TAPI weeky call

Preliminary agenda:

  • Presentation of Cisco implementation
  • Progress the review of the Reference Implementation Agreement 2.0
100 mins

Spectrum model

All

Continued the discussion on the spectrum model.

  • Capability model, provided by NEP and SIP objects.
    • Agreed that the current datatype provides all the necessary information regarding the port capability:
      • upper and lower frequency
      • adjustment granularity
      • grid type
    • Where:
      • The upper and lower frequency values may not necessarily fit the ITU-T fixed and flexible DWDM grid constraints.
      • The upper and lower frequency values may include spectrum portions which cannot be used to support services.
      • The combination of adjustment granularity and grid type informs about either ITU-T fixed or flexible grid capability.
        • E.g. if grid type = DWDM then the adjustment granularity informs about the fixed slot width.
        • E.g. if grid type = FLEX then the adjustment granularity informs about the minimum slot width (two times the adjustment granularity value).
    • Clarified that a given NEP (or SIP) may inform about more than one spectrum portion, e.g. [f1 to f2] and [f3 to f4] frequencies.
  • Provisioning model, the CSEP is augmented by OTSi (transponder), MC and OTSiMC (ROADM) specific data structures.
    • Discussion on pros and cons of N, M notation for service provisioning.
      • Gabriele Galimberti confirms that their implementation already performs the translation from TAPI spectrum to N, M notation, in other words the TAPI model is already providing all the necessary information.
    • Eventually agreed that the current TAPI provisioning model is more generic than N, M notation. In other words, the Client Controller can specify the frequency range either fulfilling the N, M constraints or not.
      • Ramon Casellas doing so we do not move the responsibility of ITU-T compliance to the Client Controller.
      • This genericity may become useful e.g. for future gridless implementations.
    • Agreed to clearly specify in the TAPI comments that the Client Controller shall not provision data which does not fulfil the capability described by NEP/SIP and in the case the Server Controller shall reject that provisioning. In other words, the upper and lower frequency values must be well formed according to described capability.
      • E.g. if grid type = FLEX and adjustment granularity = G_6_25GHZ, then the Client Controller shall not provision MC/OTSiMC which upper and lower frequency values do not respect such constraints.
    •  Gabriele Galimberti points out that provisioning exceptions shall be coded, e.g. "not supported grid constraints" or "bandwidth (partially) in use".
      • General agreement, this is a planned improvement of Reference Implementation Agreement, likely for version > 2.0
15 minsFrequency unit of measurementAll

After a brief discussion, it is agreed to move to Hz unit, given the dimension of the uint64 number.

  • Ramon Casellas clarifies that the JSON encodes the YANG uint64 as a string type, which is anyway not an issue.
  • Gabriele Galimberti highlights that the central frequency value of a transceiver may be specified with greater precision (finer than MHz) with respect to the supported adjustment granularity.