Slice Kicker service for Routing Policy, ODN ...etc: Steps:1. Create slo-sle-template (NSST)  System creates Routing Policy and Routing Policy Tags automatically.2. Create a slice use the above NSST  System creates VPN service automatically3. Edit the internal created Routing Policy or Routing Policy Tag.   I expect the kicker service will roll back to the original value but it does not.Same behavior for ODN template for the case that NSST is set as forwarding plane policy = as-blueprint. And a slice is created use this NSST. User should not be allow to edit the internal created services, Routing Policies... etc. With current design, we do not restrict users to edit internal created entries. The expectation is the kicker service will take care of this and revert back to the original data.Can you confirm if these are issues for Slice kicker service?
Thank you for your ticket. Developer working on reproducing issue.After reproducing, confirmed that service is working as designed. See below for Developer notes:Question/Answer 1:Regarding route-policy:Once the route-policy is created (By whichever service L2, L3, NSS-L2, NSS-L3) the config being pushed to the device depends solely on the l2vpn-routing-policy If a change is made under l2vpn-routing-policy/defined-sets or l2vpn-routing-policy/policy-definitions, the kickers monitoring the l2vpn-routing-policy will ensure that this new config is pushed to the device.Therefore, route-policy device config is not controlled by the service "using" the policy. It is controlled by the l2vpn-routing-policy.Question/Answer 2: Regarding ODN:Similarly, I believe is the same concept and case with ODN. The ODN template stands alone. It is being used by the NSS and pushed to the device through the NSS service. But making a change to ODN is a standalone change and will have the related effect on config.Question/Answer 3: Regarding User should not be allow to edit the internal created services, Routing Policies... etc.Yes, that is our recommendation. Because user changing internal data will result in discrepancy, exactly as in above 2 cases.Question/Answer 4: With current design, we do not restrict users to edit internal created entries.Yes, NSS is designed to use the other services (ODN, route-policy, PM etc) but it is not possible for us to hide/restrict the user from making changes to these other standalone services.If User tries to redeploy an NSS service (after making internal edits) there will be various errors seen (case by case basis). Please see below for a sample run.admin@ncs% show devices device PIOSXR-* config route-policydevice PIOSXR-0 {  config {    route-policy L2-ATTACH {      value " apply NSS-L2-P2P-evi-1-internalrn apply PASS_ALLrn";    }    route-policy NSS-L2-P2P-evi-1-internal {      value " if evpn-route-type is 1 and rd in (ios-regex '.*:(1)$') thenrn  set extcommunity color COLOR_40rn endifrn passrn";    }  }}device PIOSXR-1 {  config {    route-policy L2-ATTACH {      value " apply NSS-L2-P2P-evi-1-internalrn apply PASS_ALLrn";    }    route-policy NSS-L2-P2P-evi-1-internal {      value " if evpn-route-type is 1 and rd in (ios-regex '.*:(1)$') thenrn  set extcommunity color COLOR_40rn endifrn passrn";    }  }}device PIOSXR-2 {  config {    route-policy L2-ATTACH {      value " apply PASS_ALLrn";    }  }}admin@ncs% show | compare l2vpn-routing-policy {   defined-sets {     tag-sets {       tag-set NSS-1-internal {-        tag-value [ 1 ];+        tag-value [ 11 ];       }       tag-set NSS-2-internal {-        tag-value [ 2 ];+        tag-value [ 12 ];       }       tag-set NSS-30-internal {-        tag-value [ 30 ];+        tag-value [ 31 ];       }       tag-set NSS-40-internal {-        tag-value [ 40 ];+        tag-value [ 41 ];       }       tag-set NSS-50-internal {-        tag-value [ 50 ];+        tag-value [ 51 ];       }     }   } }admin@ncs% show devices device PIOSXR-* config route-policydevice PIOSXR-0 {  config {    route-policy L2-ATTACH {      value " apply NSS-L2-P2P-evi-1-internalrn apply PASS_ALLrn";    }    route-policy NSS-L2-P2P-evi-1-internal {      value " if evpn-route-type is 1 and rd in (ios-regex '.*:(1)$') thenrn  set extcommunity color COLOR_41rn endifrn passrn";    }  }}device PIOSXR-1 {  config {    route-policy L2-ATTACH {      value " apply NSS-L2-P2P-evi-1-internalrn apply PASS_ALLrn";    }    route-policy NSS-L2-P2P-evi-1-internal {      value " if evpn-route-type is 1 and rd in (ios-regex '.*:(1)$') thenrn  set extcommunity color COLOR_41rn endifrn passrn";    }  }}device PIOSXR-2 {  config {    route-policy L2-ATTACH {      value " apply PASS_ALLrn";    }  }}admin@ncs% request network-slice-services slice-service L2-P2P re-deployError: too many 'l2vpn-routing-policy defined-sets tag-sets tag-set NSS-40-internal tag-value', 2 configured, at most 1 must be configuredCorrect me if I am wrong for the summary:The kicker service will only take care of VPN service change, but not for other items (ODN, routing policiesetc). For example, a slice is created. 1. user edit internal vpn service: it will roll back to the original config.2. user edit ODN: slice config and the internal ODN config are different now. Since the ODN config is changed on device, but slice config. still remain the old data.3. user edit Routing policies: same behavior as item 2.Hi Crystal, Yes this correct.Also confirmed with our QA and it is correct.Regards,Janaki DuggiralaCustomer confirmed ticket can be closed.