Whether NSO model available to load for some transport slicing attributes.: Hi,Is there any NSO model available to load possible values for below attributes,1. Connectivity Type (slice service)2. Peering Protocol (slice service)3. Forward plane Policy type ( slice template)We need the possible values to be loaded in CNC for these attributes.Thanks,
<ol>Connectivity Type (slice service) => Released with M2Peering Protocol (slice service) => Released with M2Forward plane Policy type ( slice template) => Will be released with M4</ol>I've given the following cut down yang tree which has the both "connectivity-type" and "sdp-peering"<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"><pre>module: ietf-network-slice-service +--rw network-slice-services +--rw slice-service* [service-id] | +--rw service-id string | +--rw connection-groups | | +--rw connection-group* [connection-group-id] | | +--rw connection-group-id string | | +--rw connectivity-type? identityref | +--rw sdps | | +--rw sdp* [sdp-id] | | +--rw sdp-id string | | +--rw sdp-peering | | | +--rw protocol* [protocol-type] | | | +--rw protocol-type identityref | | | +--rw cisco-nss:bgp-attributes | | | +--rw (as-type)? | | | +--:(as-no-from-device) | | | +--rw cisco-nss:as-no-from-device? empty | | +--rw attachment-circuits | | | +--rw attachment-circuit* [ac-id] | | | +--rw ac-id string | | | +--rw sdp-peering | | | +--rw protocol* [protocol-type] | | | +--rw protocol-type identityref | | | +--rw cisco-nss:bgp-attributes! | | | +--rw cisco-nss:neighbor* inet:ip-address | | | +--rw cisco-nss:remote-as inet:as-number | | | +--rw cisco-nss:update-source! | | | | +--rw cisco-nss:if-type enumeration | | | | +--rw cisco-nss:if-id string | | | | +--rw cisco-nss:sub-if-id? int32 | | | +--rw cisco-nss:mpls-deactivation? boolean | | | +--rw cisco-nss:multihop? uint8</pre></div></div>Let me know if the above helps.Thanks,RegiHi,It looks like possible values for1. connectivityType : Any To-Any , Hub And Spoke 2. Peering Protocol : BGPIs these values are hardcoded or it is loaded from some other nso model.This will help us to leverage the same model instead of hard coding it in CNC. We are asking it since there is a possibility new values will be added in future ; we will end up changing it everytime.Thanks,NaveenHi,These are derived from IETF Models: connectivity-type uses "vpn-common:vpn-topology" type, so it's coming from the vpn-common module:<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"><pre>    leaf connectivity-type {     type identityref {      base vpn-common:vpn-topology;     }     default "vpn-common:any-to-any";     description      "Connection group connectivity type.";    }</pre></div></div>However, we do restrict the above types to what we currently support.SDP Peering is part of IETF as well as "peering-protocol-type" is defined in the IETF slicing module:<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"><pre>   grouping sdp-peering {    description     "A grouping for the slice service SDP peering.";    container sdp-peering {     description      "Describes SDP peering attributes.";     list protocol {      key "protocol-type";      description       "List of the SDP peering protocol.";      leaf protocol-type {       type identityref {        base peering-protocol-type;       }       description        "Identifies an entry in the list of SDP peering        protocol type.";      }</pre></div></div>but the "bgp-attributes" container is a cisco addition as you can see from the previous yang tree as there's a namespace prefix.Thanks,Regi