[GBP-51] Ensure SFC Yang models are complete such that SF can leverage them to modify metadata Created: 20/May/15  Updated: 15/Jun/15  Due: 27/May/15  Resolved: 15/Jun/15

Status: Resolved
Project: groupbasedpolicy
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Keith Burns Assignee: Thomas Bachman
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 3307
Priority: Normal

 Description   

This is a check of the yang. not an implementation of this functionality.

 Comments   
Comment by Thomas Bachman [ 27/May/15 ]

Thanks to Andrej Kincel who pointed me to the right place in the code. The service-function.yang model has a separate container/list for Service Function state:

container service-functions-state {
description
"This container hold operational state for all service
functions";
config false;
list service-function-state {
description
"This list holds operational data for all service functions
in the domain";
key "name";
leaf name

{ type string; description "the name of the service function"; }

uses sfc-ss:service-statistics-group

{ description "Global Service Function statistics"; }

list sf-service-path {
key "name";
leaf name

{ type string; description "The name of the Service Path"; }

etc.

The code updates the sf-service-path in the operational data store using the RSP name. The RSP contains:

list rendered-service-path {
description
"A list that holds operational data for all RSPs in the
domain";
key "name";
leaf name

{ type string; description "The name of this rendered function path. This is the same name as the associated SFP"; }

....
leaf context-metadata

{ type sfc-md:context-metadata-ref; description "The name of the associated context metadata"; }

leaf variable-metadata

{ type sfc-md:variable-metadata-ref; description "The name of the associated variable metadata"; }

It's not ideal, as the state is kept in a separate list, rather than contained within the SF itself. In short, it means that the SF has to look it's own name up in the service-function-state list, get the service-path name, and then look up the rendered-service-path by name to get the metadata fields.

Generated at Wed Feb 07 20:01:00 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.