Reporting a client the TE Topology profile a server has implemented

[italobusi]

It is not clear how it is possible to report to a client the TE topology profiles that a server has implemented

• Not an issue when reading the operational DS
• Issue when writing to running DS How to avoid the client to write an attribute not used in the TE Topology profile implemented by the server

Is it a general issue?

• How to avoid the client to write an optional attribute which is not supported by the server

[italobusi]

Triggered some discussion in Netmod WG:

https://mailarchive.ietf.org/arch/msg/netmod/8wsAyGazqi7KqgFHz9VK-7vuzHc/

This seems an issue to be addressed by TEAS

[italobusi]

2021-09-10 TE Call

+--network-topology
  +--rw supported-network-profiles*     string
  +--rw network
     +--rw network-te-profile*     leafref

Client can write the network-te-profile to request the server to implement only some profiles for a given topology instance

Server report in the network-te-profile which profile has been implemented by a given topology instance

Client can write supported-te-profiles to request the server which profile implemented by the server should be used

---

Server reports in the supported-te-profiles the profiles it has implemented (e.g., uni, status, geolocation)

Client can request the server to implement a sub-set of its supported profiles (e.g., uni, status):

• write the supported-network-profiles

---

Server capability: A, B, C, D

Client 1: A, B Client 2: B, C

operational-DS: union (A, B, C, D)

rpc get-profile-topology

• requested-profiles*
• network-topology (same tree)

---

Should we find a generic solution which can be used with other models (e.g., te-tunnel) or different similar solutions for te-topology and te-tunnel model?

---

The plan is to progress this issue before requesting WG adoption

[italobusi]

2021-10-08 TE Call

+--network-topology
  +--ro supported-network-profiles*     identityref
  +--ro requested-network-profiles* [ client-id network-profile]
    +--ro client-id                client-id
    +--ro network-profile    identityref

Server reports the profiles it has implemented (e.g., uni, status, geolocation):

• in the supported-network-profiles within the operational datastore

For example, the server can report that it can support the following profiles:

• supported-network-profiles: [ A, B, C, D ]

Client can request the server to implement a sub-set of its supported profiles (e.g., uni, status):

• through a request-network-profiles RPC

For example, the server can report that it can support the following profiles:

• Client 1: request-network-profile [A, B]
• Client 2: request-network-profile [B, C]

Client 1 can only set the leaves in common between profiles A and B in the running DS and only ready leaves in common between profiles A and B in both running and operational DSes.

Client 2 can only set the leaves in common between profiles B and C in the running DS and only ready leaves in common between profiles B and C in both running and operational DSes.

This information can be available as read-only in the operational DS (similar mechanism as YANG notification subscription)

Not requesting a request-network-profile RPC or requesting a request-network-profile RPC with an empty list is equivalent as requesting all the profiles being supported by the server.

[italobusi]

The profile of the TE topology should also take into account the optional attributes defined in the technology-specific augmentation models. See for example: https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/92