Here's a pointer to the demo that Pam gave on this topic: 

zoom_0.mp4


Since there're big changes in the config that we send to Policy framework for policy retrieval, we need to modify our code accordingly to match that logic.

Config changes in policy retrieval

Legacy Config Example

The legacy config we sent for policy retrieval contains the prefix for each release, the geography info as well as the service information. 

#Scope with geography
{ "policyName": "OSDF_DUBLIN.*",
  "configAttributes": {"policyScope": "us"} 

#Scope with service name
{ "policyName": "OSDF_DUBLIN.*",
  "configAttributes": {"policyScope": "vfw"}

New Config Example

In the new config we sent for policy retrieval, the prefix is no longer needed. And for the geography and service name, the values need to be put under certain keys.

{"ONAPName": "OOF",
 "ONAPComponent": "OSDF",
 "ONAPInstance": "",
 "action": "optimize",
 "resource": {
     "geography": "us",
     "services": "vfw"
     "scope": "xxx" //Optional
 }}

Change in OSDF common config

Legacy configuration in common.config and also a draft config according to the new payload.

...
policy_info:
    prioritization_attributes:
        policy_type:
            - content.policyType
        resources:
            - content.resources
            - content.objectiveParameter.parameterAttributes.resources
        service_name:
            - content.serviceName

    placement:
        policy_fetch: by_scope
        policy_scope:
            default_scope: OSDF_DUBLIN     //This part could be removed
            vcpe_scope: OSDF_DUBLIN
            vfw_scope: OSDF_DUBLIN
            td_scope: OSDF_DUBLIN
            secondary_scopes:
                -
                    - get_param: service_name //Better to be changed as KV pair
                    - US
    #            -
    #                - get_param: service_name
    #                - get_param: subscriber_role
    default:  # if no explicit service related information is needed
        policy_fetch: by_name
        policy_scope: none

Draft common config for OSDF

...
policy_info:
    prioritization_attributes:
        policy_type:
            - content.policyType
        resources:
            - content.resources
            - content.objectiveParameter.parameterAttributes.resources
        service_name:
            - content.serviceName

    placement:
        policy_fetch: by_scope
        policy_scope:
            - scopes:   //needed or not?
                - geography:
                    - US
                - services:
                    - get_param: service_name
                - scope
                    - get_param: subscriber_role
    #            -
    #                - get_param: service_name
    #                - get_param: subscriber_role
    default:  # if no explicit service related information is needed
        policy_fetch: by_name
        policy_scope: none


Change in code

Change in the rest call to policy framework

Since we totally change the uri to call with, there're quite many changes in the rest call.

A. The header 'ClientAuth' and 'Environment' are no longer needed.

B. The uri, username and password should be changed accordingly.

Changes: https://git.onap.org/optf/osdf/tree/osdf/adapters/policy/interface.py

Change in retrieval method

Do we still need that get_by_name method in OSDF?

Changes: https://git.onap.org/optf/osdf/tree/osdf/adapters/policy/interface.py


Meeting minutes - 2019/10/23

Changes for OSDF retrieving code:

A. Url, authentication(user and pass), extra headers

B. payload send for retrieval.

Using the new filters(geography, service, resource, scope, name?)

AR: Ask Pam about the implementation of scope(assign with multiple values?) – Ruoyu Ying

      Check if the policy name filter still exists in the current implementation – Ruoyu Ying

 C. Config for OSDF

Put the new filters inside the config 

Add two new question from Ruoyu Ying :

  1. Where does the input for geography and scope come from? Does user need to modify the config file each time they want to change?

       2. Will the object 'scope' be added as a mandatory value in our payload to Policy framework?

 Avteet Chayal Shankaranarayanan Puzhavakath Narayanan   

D. Clean up the source code where does the filtering job ourselves by resource name

E. Clean up the source code where provides choice for retrieving(by scope or by name)

AR: Confirm if retrieving by name is still needed – Avteet Chayal


Examples of policy retrieval

Occasion one: Normal way
#Available policies inside the policy db
- 
        OSDF_CASABLANCA.Affinity_Default_vCPE_US_0:
            type: onap.policies.optimization.AffinityPolicy
            version: 1.0.0
            type_version: 1.0.0
            metadata:
                policy-id: OSDF_CASABLANCA.Affinity_Default_vCPE_US_0
                policy-version: 1
            properties:
                scope: [OSDF_FRANKFURT]
                services: [vCPE]
                resources: [vG]
                geography: [US]
                identity: affinity_vCPE
                applicableResources: any
                affinityProperties:
                    qualifier: different
                    category: complex

- 
        OSDF_CASABLANCA.Affinity_Default_vCPE_US_1:
            type: onap.policies.optimization.AffinityPolicy
            version: 1.0.0
            type_version: 1.0.0
            metadata:
                policy-id: OSDF_CASABLANCA.Affinity_Default_vCPE_US_0
                policy-version: 1
            properties:
                scope: [OSDF_FRANKFURT]
                services: [vCPE]
                resources: [vGMux]
                geography: [US]
                identity: affinity_vCPE
                applicableResources: any
                affinityProperties:
                    qualifier: different
                    category: complex


# VFC Request
{  
    "requestInfo":{  
        "transactionId":"12348659-a547-4b81-954e-a244fc5f0f9e",
        "requestId":"12348659-a547-4b81-954e-a244fc5f0f9e",
        "callbackUrl":"http://10.42.57.133:8403/api/nslcm/v1/ns/placevnf",
        "sourceId":"vfc",
        "requestType":"create",
        "numSolutions":1,
        "optimizers":[  
            "placement"
        ],
        "timeout":600
    },
    "placementInfo":{  
        "requestParameters":{  
            "customerLatitude":"32.897480",
            "customerLongitude":"97.040443",
            "customerName":"some_company"
        },
        "subscriberInfo":{  
            "globalSubscriberId":"",
            "subscriberName":"",
            "subscriberCommonSiteId":""
        },
        "placementDemands":[  
            {  
                "resourceModuleName":"vG",
                "serviceResourceId":"f0a16496-2e0a-480b-8486-04ef762d1d2d",
                "tenantId":"null",
                "resourceModelInfo":{  
                    "modelInvariantId":"c01e991e-b687-4875-8d75-d6888637f175",
                    "modelVersionId":"c00456ac-c9b5-4f72-87ae-3a4a0eec6fba",
                    "modelName":"7400fd06-c75f-4a44-a68f",
                    "modelType":"",
                    "modelVersion":"1.0",
                    "modelCustomizationName":""
                }
            },
            {  
                "resourceModuleName":"vGMux",
                "serviceResourceId":"f0a16496-2e0a-480b-8486-04ef762d1d2e",
                "tenantId":"null",
                "resourceModelInfo":{  
                    "modelInvariantId":"c01e991e-b687-4875-8d75-d6888637f176",
                    "modelVersionId":"c00456ac-c9b5-4f72-87ae-3a4a0eec6fbb",
                    "modelName":"7400fd06-c75f-4a44-a68g",
                    "modelType":"",
                    "modelVersion":"1.0",
                    "modelCustomizationName":""
                }
            }
        ]
    },
    "serviceInfo":{  
        "serviceInstanceId":"83a23b7a-e68e-4496-a3b2-3bfd822ed63b",
        "serviceName":"vcpe",
        "modelInfo":{  
            "modelType":"",
            "modelInvariantId":"0d9312af-96fa-425c-b732-01eeca3c3490",
            "modelVersionId":"65f761a4-45db-4cde-8d7c-ef9512585098",
            "modelName":"vCPE 2018-10-31 19:17:04",
            "modelVersion":"1.0",
            "modelCustomizationName":""
        }
    }
}

#Retrieval plans
Plan A: If we are going to send only one policy request per VFC request to get all policies, the config need to have two resources both appeared in the 'resources' filter which shall look like this:
        Config:     {"ONAPName": "OOF",
                     "ONAPComponent": "OOF_Component",
                     "ONAPInstance": "OOF_Component_Instance",
                     "action": "optimize",
                     "resources": "{
                        "services": ["vcpe"],
                        "geography": ["US"],
                        "resources": ["vG", "vGMux"],
                        "scope": ["OSDF_FRANKFURT"] }"
        However, if we send out a request like this, neither of the policies should be fetched.

NOTE: 12/3 per PLD - you will actually get BOTH policies from this. The items within each LHS are treated as OR, whereas each line is treated is an AND.

vcpe AND US AND (vg OR vGMux) AND OSDF_FRANKFURT


Plan B: If we are going to send multiple policy requests(one request per vnf), there would be two separate configs with different values inside the key 'resources':
        Config A:   {"ONAPName": "OOF",
                     "ONAPComponent": "OOF_Component",
                     "ONAPInstance": "OOF_Component_Instance",
                     "action": "optimize",
                     "resources": "{
                        "services": ["vcpe"],
                        "geography": ["US"],
                        "resources": ["vG"],
                        "scope": ["OSDF_FRANKFURT"] }"
       Config B:    {"ONAPName": "OOF",
                     "ONAPComponent": "OOF_Component",
                     "ONAPInstance": "OOF_Component_Instance",
                     "action": "optimize",
                     "resources": "{
                        "services": ["vcpe"],
                        "geography": ["US"],
                        "resources": ["vGMux],
                        "scope": ["OSDF_FRANKFURT"] }"
      In this way, each policy will be respond to OSDF for certain request.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Occasion 2: Only one default policy available in policy db
#Available policies inside the policy db
-
        OSDF_CASABLANCA.Affinity_Default_US:
            type: onap.policies.optimization.AffinityPolicy
            version: 1.0.0
            type_version: 1.0.0
            metadata:
                policy-id: OSDF_CASABLANCA.Affinity_Default_US
                policy-version: 1
            properties:
                scope: [OSDF_FRANKFURT]
                services: [vCPE]
                resources: []
                geography: [US]
                identity: affinity_vCPE
                applicableResources: any
                affinityProperties:
                    qualifier: same
                    category: complex

# A same homing request is then made to OOF
{  
    "requestInfo":{  
        "transactionId":"12348659-a547-4b81-954e-a244fc5f0f9e",
        "requestId":"12348659-a547-4b81-954e-a244fc5f0f9e",
        "callbackUrl":"http://10.42.57.133:8403/api/nslcm/v1/ns/placevnf",
        "sourceId":"vfc",
        "requestType":"create",
        "numSolutions":1,
        "optimizers":[  
            "placement"
        ],
        "timeout":600
    },
    "placementInfo":{  
        "requestParameters":{  
            "customerLatitude":"32.897480",
            "customerLongitude":"97.040443",
            "customerName":"some_company"
        },
        "subscriberInfo":{  
            "globalSubscriberId":"",
            "subscriberName":"",
            "subscriberCommonSiteId":""
        },
        "placementDemands":[  
            {  
                "resourceModuleName":"vG",
                "serviceResourceId":"f0a16496-2e0a-480b-8486-04ef762d1d2d",
                "tenantId":"null",
                "resourceModelInfo":{  
                    "modelInvariantId":"c01e991e-b687-4875-8d75-d6888637f175",
                    "modelVersionId":"c00456ac-c9b5-4f72-87ae-3a4a0eec6fba",
                    "modelName":"7400fd06-c75f-4a44-a68f",
                    "modelType":"",
                    "modelVersion":"1.0",
                    "modelCustomizationName":""
                }
            },
            {  
                "resourceModuleName":"vGMux",
                "serviceResourceId":"f0a16496-2e0a-480b-8486-04ef762d1d2e",
                "tenantId":"null",
                "resourceModelInfo":{  
                    "modelInvariantId":"c01e991e-b687-4875-8d75-d6888637f176",
                    "modelVersionId":"c00456ac-c9b5-4f72-87ae-3a4a0eec6fbb",
                    "modelName":"7400fd06-c75f-4a44-a68g",
                    "modelType":"",
                    "modelVersion":"1.0",
                    "modelCustomizationName":""
                }
            }
        ]
    },
    "serviceInfo":{  
        "serviceInstanceId":"83a23b7a-e68e-4496-a3b2-3bfd822ed63b",
        "serviceName":"vcpe",
        "modelInfo":{  
            "modelType":"",
            "modelInvariantId":"0d9312af-96fa-425c-b732-01eeca3c3490",
            "modelVersionId":"65f761a4-45db-4cde-8d7c-ef9512585098",
            "modelName":"vCPE 2018-10-31 19:17:04",
            "modelVersion":"1.0",
            "modelCustomizationName":""
        }
    }
}

#Retrieval plans
Plan A: If we are going to send only one policy request per VFC request to get all policies, the config should contain both resources in the 'resources' filter which shall look like this:
        Config:     {"ONAPName": "OOF",
                     "ONAPComponent": "OOF_Component",
                     "ONAPInstance": "OOF_Component_Instance",
                     "action": "optimize",
                     "resources": "{
                        "services": ["vCPE"],
                        "geography": ["US"],
                        "resources": ["vG, vGMux"],
                        "scope": ["OSDF_FRANKFURT"] }"
        Both of the policies will be fetched.

Plan B: If we are going to send multiple policy requests(one request per vnf), there would be two separate configs with different values inside the key 'resources':
        Config A:   {"ONAPName": "OOF",
                     "ONAPComponent": "OOF_Component",
                     "ONAPInstance": "OOF_Component_Instance",
                     "action": "optimize",
                     "resources": "{
                        "services": ["vcpe"],
                        "geography": ["US"],
                        "resources": ["vG"],
                        "scope": ["OSDF_FRANKFURT"] }"
       Config B:    {"ONAPName": "OOF",
                     "ONAPComponent": "OOF_Component",
                     "ONAPInstance": "OOF_Component_Instance",
                     "action": "optimize",
                     "resources": "{
                        "services": ["vcpe"],
                        "geography": ["US"],
                        "resources": ["vGMux],
                        "scope": ["OSDF_FRANKFURT"] }"
      In this way, the default policy will be respond to OSDF for certain request.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Occasion 3: One default policy and one specific policy available in policy db
#Available policies inside the policy db
-
        OSDF_CASABLANCA.Affinity_Default_US:
            type: onap.policies.optimization.AffinityPolicy
            version: 1.0.0
            type_version: 1.0.0
            metadata:
                policy-id: OSDF_CASABLANCA.Affinity_Default_US
                policy-version: 1
            properties:
                scope: [OSDF_FRANKFURT]
                services: [vCPE]
                resources: []
                geography: [US]
                identity: affinity_vCPE
                applicableResources: any
                affinityProperties:
                    qualifier: same
                    category: complex

-      OSDF_CASABLANCA.Affinity_US_vG:
            type: onap.policies.optimization.AffinityPolicy
            version: 1.0.0
            type_version: 1.0.0
            metadata:
                policy-id: OSDF_CASABLANCA.Affinity_Default_US
                policy-version: 1
            properties:
                scope: [OSDF_FRANKFURT]
                services: [vCPE]
                resources: [vG]
                geography: [US]
                identity: affinity_vCPE
                applicableResources: any
                affinityProperties:
                    qualifier: same
                    category: complex

# A same homing request is then made to OOF
{  
    "requestInfo":{  
        "transactionId":"12348659-a547-4b81-954e-a244fc5f0f9e",
        "requestId":"12348659-a547-4b81-954e-a244fc5f0f9e",
        "callbackUrl":"http://10.42.57.133:8403/api/nslcm/v1/ns/placevnf",
        "sourceId":"vfc",
        "requestType":"create",
        "numSolutions":1,
        "optimizers":[  
            "placement"
        ],
        "timeout":600
    },
    "placementInfo":{  
        "requestParameters":{  
            "customerLatitude":"32.897480",
            "customerLongitude":"97.040443",
            "customerName":"some_company"
        },
        "subscriberInfo":{  
            "globalSubscriberId":"",
            "subscriberName":"",
            "subscriberCommonSiteId":""
        },
        "placementDemands":[  
            {  
                "resourceModuleName":"vG",
                "serviceResourceId":"f0a16496-2e0a-480b-8486-04ef762d1d2d",
                "tenantId":"null",
                "resourceModelInfo":{  
                    "modelInvariantId":"c01e991e-b687-4875-8d75-d6888637f175",
                    "modelVersionId":"c00456ac-c9b5-4f72-87ae-3a4a0eec6fba",
                    "modelName":"7400fd06-c75f-4a44-a68f",
                    "modelType":"",
                    "modelVersion":"1.0",
                    "modelCustomizationName":""
                }
            },
            {  
                "resourceModuleName":"vGMux",
                "serviceResourceId":"f0a16496-2e0a-480b-8486-04ef762d1d2e",
                "tenantId":"null",
                "resourceModelInfo":{  
                    "modelInvariantId":"c01e991e-b687-4875-8d75-d6888637f176",
                    "modelVersionId":"c00456ac-c9b5-4f72-87ae-3a4a0eec6fbb",
                    "modelName":"7400fd06-c75f-4a44-a68g",
                    "modelType":"",
                    "modelVersion":"1.0",
                    "modelCustomizationName":""
                }
            }
        ]
    },
    "serviceInfo":{  
        "serviceInstanceId":"83a23b7a-e68e-4496-a3b2-3bfd822ed63b",
        "serviceName":"vcpe",
        "modelInfo":{  
            "modelType":"",
            "modelInvariantId":"0d9312af-96fa-425c-b732-01eeca3c3490",
            "modelVersionId":"65f761a4-45db-4cde-8d7c-ef9512585098",
            "modelName":"vCPE 2018-10-31 19:17:04",
            "modelVersion":"1.0",
            "modelCustomizationName":""
        }
    }
}

#Retrieval plans
Plan A: If we are going to send only one policy request per VFC request to get all policies, the config should contain both resources in the 'resources' filter which shall look like this:
        Config:     {"ONAPName": "OOF",
                     "ONAPComponent": "OOF_Component",
                     "ONAPInstance": "OOF_Component_Instance",
                     "action": "optimize",
                     "resources": "{
                        "services": ["vCPE"],
                        "geography": ["US"],
                        "resources": ["vG, vGMux"],
                        "scope": ["OSDF_FRANKFURT"] }"
        Will both of the policies being fetched? Since the second policy instance is more fine-grained.

Plan B: If we are going to send multiple policy requests(one request per vnf), there would be two separate configs with different values inside the key 'resources':
        Config A:   {"ONAPName": "OOF",
                     "ONAPComponent": "OOF_Component",
                     "ONAPInstance": "OOF_Component_Instance",
                     "action": "optimize",
                     "resources": "{
                        "services": ["vcpe"],
                        "geography": ["US"],
                        "resources": ["vG"],
                        "scope": ["OSDF_FRANKFURT"] }"
       Config B:    {"ONAPName": "OOF",
                     "ONAPComponent": "OOF_Component",
                     "ONAPInstance": "OOF_Component_Instance",
                     "action": "optimize",
                     "resources": "{
                        "services": ["vcpe"],
                        "geography": ["US"],
                        "resources": ["vGMux],
                        "scope": ["OSDF_FRANKFURT"] }"
      In this way, the default policy will be respond to OSDF for vGMux and the specific policy will be respond to vG.

Question:

A. Would there be chances that certain policy is intended to be working for a certain service but rather than a vnf.

Currently, Subscriber policy and Query policy are verified that they are used per service level.

Keys needed are 'services'. 'scope' and 'geography'.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Other policies including Vnf policy, Distance policy, Affinity policy, HPA policy, Optimization policy and Capacity(Vim-fit) policy are used per VNF level

Keys needed are 'services', 'scope', 'geography' and 'resources' which fits our current implementation.


Extra thing: Shankaranarayanan Puzhavakath Narayanan Lukasz Rajewski I got a question on the TD Query policies. I just checked the sample TD query policies inside the repo and find that the 'resources' field is also added. Any reason the request parameters are applied for certain vnf?


B. TD policies slightly different to other optimization policies, which they are most likely related with TD functionality rather than with concrete service or VNF.

So we planned to change overall policy type to 'demand' to cover TD and other normal policies for certain VNF, and have a separate policy type to cover other policies which are used per service level.


  • No labels

3 Comments

  1. Shankaranarayanan Puzhavakath Narayanan

    Ruoyu Ying I don't think the examples here are reflective of the closest match logic, can you please help me understand the expectation and intent of these policies ? For instance, Occasion 1 plan A wouldn't retrieve any policies, since both the Affinity policy instances are more specific than the config  "vcpe", "US", "OSDF_FRANKFURT". For it to work the way in the example, I'm guessing we'd need a more generic policy instances like the ones below. For the specific config in occasion 1-plan A, the presence of any of the following (A), (B) or (C) will retrieve the affinity policy, with (A) being the closest match if (A), (B) and (C) are present simultaneously. Please let me know if this makes sense. 

    Pamela Dragosh, please confirm if this understanding is correct. 

    (A):  broader than the resource specific Affinity policy - applies to any resource that is deployed for vCPE deployed in US, for OSDF_FRANKFURT release

    OSDF_CASABLANCA.Affinity_Default_vCPE_US_2:
                type: onap.policies.optimization.AffinityPolicy
                version: 1.0.0
                type_version: 1.0.0
                metadata:
                    policy-id: OSDF_CASABLANCA.Affinity_Default_vCPE_US_0
                    policy-version: 1
                properties:
                    scope: [OSDF_FRANKFURT]
                    services: [vCPE]
                    resources: []
                    geography: [US]
                    identity: affinity_vCPE
                    applicableResources: any
                    affinityProperties:
                        qualifier: different
                        category: complex


    (B):  broader than (A) – applies to all services and resources, deployed in US for OSDF_FRANKFURT release

    OSDF_CASABLANCA.Affinity_Default_US:
                type: onap.policies.optimization.AffinityPolicy
                version: 1.0.0
                type_version: 1.0.0
                metadata:
                    policy-id: OSDF_CASABLANCA.Affinity_Default_vCPE_US_0
                    policy-version: 1
                properties:
                    scope: [OSDF_FRANKFURT]
                    services: []
                    resources: []
                    geography: [US]
                    identity: affinity_vCPE
                    applicableResources: any
                    affinityProperties:
                        qualifier: different
                        category: complex



    (C):  broader than (B) - applies to all services deployed for OSDF_FRANKFURT release


    OSDF_CASABLANCA.Affinity_Default:
                type: onap.policies.optimization.AffinityPolicy
                version: 1.0.0
                type_version: 1.0.0
                metadata:
                    policy-id: OSDF_CASABLANCA.Affinity_Default_vCPE_US_0
                    policy-version: 1
                properties:
                    scope: [OSDF_FRANKFURT]
                    services: []
                    resources: []
                    geography: []
                    identity: affinity_vCPE
                    applicableResources: any
                    affinityProperties:
                        qualifier: different
                        category: complex


    1. Ruoyu Ying

      Hi Shankaranarayanan Puzhavakath Narayanan, I think i got that point now. So let me modify the examples here. So there's still need to be a separate request to the policy framework for each resource, correct? Otherwise, it can only find the appropriate policies that fits both two. 

      Example:

      Config:     {"ONAPName": "OOF",
                           "ONAPComponent": "OOF_Component",
                           "ONAPInstance": "OOF_Component_Instance",
                           "action": "optimize",
                           "resources": "{
                              "services": ["vcpe"],
                              "geography": ["US"],
                              "resources": ["vG", "vGMux"],
                              "scope": ["OSDF_FRANKFURT"] }"

      Is shall NOT fetch policy A like this, correct?

      Policy A:

      OSDF_CASABLANCA.Affinity_vCPE_US_2:
                  type: onap.policies.optimization.AffinityPolicy
                  version: 1.0.0
                  type_version: 1.0.0
                  metadata:
                      policy-id: OSDF_CASABLANCA.Affinity_Default_vCPE_US_0
                      policy-version: 1
                  properties:
                      scope: [OSDF_FRANKFURT]
                      services: [vCPE]
                      resources: [vG]
                      geography: [US]
                      identity: affinity_vCPE
                      applicableResources: any
                      affinityProperties:
                          qualifier: different
                          category: complex

      But it is ABLE to fetch a policy B like this?

      Policy B

      OSDF_CASABLANCA.Affinity_vCPE_US_3:
                  type: onap.policies.optimization.AffinityPolicy
                  version: 1.0.0
                  type_version: 1.0.0
                  metadata:
                      policy-id: OSDF_CASABLANCA.Affinity_Default_vCPE_US_0
                      policy-version: 1
                  properties:
                      scope: [OSDF_FRANKFURT]
                      services: [vCPE]
                      resources: []
                      geography: [US]
                      identity: affinity_vCPE
                      applicableResources: any
                      affinityProperties:
                          qualifier: different
                          category: complex

  2. Lukasz Rajewski

    Ruoyu Ying Shankaranarayanan Puzhavakath Narayanan Frankly speaking if use of Resources on Query level is necessary in TD case. I am not sure how policy retrieval mechanism works today, that's why maybe some unnecessary constraints in the policies used. The best would be to discuss about it during weekly meeting or to organize some ad hoc call about it. TD polices are specific to TD use case so different than standard vFW policies. For TD we have vnf polices different for vPGN and for vFW-SINK demand. query policies are the same for vFW-SINK and vPGN demand so maybe TD scope would be enough. In general TD policies are more related with TD functionality rather than with concrete service or VNF so should be the same for all VNFs and all the demands. So only one query, one affinity and one vnf policy without resource but with TD scope. Makes it sense?