Constraints in topology-constraint: include-link&include-node

[wangqilei]

May I suggest the description in the below two Yang lists be changed to: "This is a loose constraint - that is it could be unordered or ordered, and could be a partial list " ? It's because during the implentation, we found that an ordered list could increase efficiency.

   list include-link {
        uses tapi-topology:link-ref;
        key 'topology-uuid link-uuid';
        config false;
        **description "This is a loose constraint - that is it is unordered and could be a partial list ";**
    }
    list include-node {
        uses tapi-topology:node-ref;
        key 'topology-uuid node-uuid';
        config false;
        **description "This is a loose constraint - that is it is unordered and could be a partial list";**
    }

Thanks Qilei

[nigel-r-davis]

The challenge is that the client may not, and probably does not, know the optimum order. If you force order specification on the client then it needs to do a path computation to determine the best order. This would suggest that the whole path calculation then should be done at the client level. The intention is that the provider determines the best order. If there is a distinct order required, perhaps dues to some peripheral functions present at the nodes such as a test capability, then maybe there is a need to enable the client to specify that the list is in order or where there are order dependencies.

From: wangqilei notifications@github.com Sent: 11 January 2019 07:18 To: OpenNetworkingFoundation/TAPI TAPI@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [EXTERNAL] [OpenNetworkingFoundation/TAPI] Constraints in topology-constraint: include-link&include-node (#381)

May I suggest the description in the below two Yang lists be changed to: "This is a loose constraint - that is it could be unordered or ordered, and could be a partial list " ? It's because during the implentation, we found that an ordered list could increase efficiency.

list include-link {

    uses tapi-topology:link-ref;

    key 'topology-uuid link-uuid';

    config false;

    **description "This is a loose constraint - that is it is unordered and could be a partial list ";**

}

list include-node {

    uses tapi-topology:node-ref;

    key 'topology-uuid node-uuid';

    config false;

    **description "This is a loose constraint - that is it is unordered and could be a partial list";**

}

Thanks Qilei

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/OpenNetworkingFoundation/TAPI/issues/381, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIejZz4c8Bf0UO4oFK1sLqawfT_U6yBJks5vCDqvgaJpZM4Z668x.

[wangqilei]

Thanks Nigel. I agree with you. Sometimes, we may need the order specified.

[amazzini]

This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.