The article introduces some notices while using Tester to send out BGP SRTE policy.

BGP SR policy path failed to be installed into inetcolor.0
 

Topo:
[Tester-Controller] --- [Router1] --- [Router2]

Router1 received BGP SRTE policy from Tester and install at bgp.inetsrte.0 , but do not install at inetcolor.0

{master}
Router1> show route table bgp.inetsrte.0

bgp.inetsrte.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.255.2-10<sr>/96                
                   *[BGP/170] 00:00:13, localpref 10, from 172.16.255.100
                      AS path: I, validation-state: unverified
                    >  to 172.16.255.2

{master}
Router1> show route table inetcolor.0       

{master}
Router1> show route table bgp.inetsrte.0 extensive 

bgp.inetsrte.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
172.16.255.2-10<sr>/96 (1 entry, 0 announced)
        *BGP    Preference: 170/-11
                SRTE Policy Path:
                   Flags Indicating Recv TLVs: <Pref, BSID>
                   Path preference: 10
                   Binding-SID: 2
                   Advertised Policy Name: bgp-srte-172.16.255.100-0-172.16.255.2-10
                   Segment list:
                      Weight: 1
                      Label: 10006       ttl: Local-ttl-policy
                Next hop type: Fictitious, Next hop index: 0
                Address: 0x93aaffc
                Next-hop reference count: 1
                Kernel Table Id: 0
                Source: 172.16.255.100
                Next hop: 172.16.255.2
                State: <Active Int Ext>
                Local AS: 64496 Peer AS: 64496
                Age: 26 
                Validation State: unverified 
                Task: BGP_64496.172.16.255.100
                AS path: I 
                Communities: target:172.16.255.100:4
                Accepted
                Localpref: 10
                Router ID: 172.16.255.100
                Thread: junos-main 

4.1.  Advertisement of SR Policies

   ......
   The distinguisher of each SR Policy NLRI prevents undesired BGP route
   selection among these SR Policy NLRIs and allows their propagation
   across route reflectors [RFC4456].

   Moreover, one or more route targets SHOULD be attached to the
   advertisement, where each route target identifies one or more
   intended headends for the advertised SR Policy update.

   If no route target is attached to the SR Policy NLRI, then it is
   assumed that the originator sends the SR Policy update directly
   (e.g., through a BGP session) to the intended receiver. In such a
   case, the NO_ADVERTISE community [RFC1997] MUST be attached to the SR
   Policy update (see further details in Section 4.2.3).
   ......

4.2.2.  Eligibility for Local Use of an SR Policy NLRI

   An SR Policy NLRI update without any route target extended community
   but having the NO_ADVERTISE community is considered usable.

  If one or more route targets are present, then at least one route
   target MUST match the BGP Identifier of the receiver for the update
   to be considered usable.  The BGP Identifier is defined in [RFC4271]
   as a 4-octet IPv4 address.  Therefore, the route target extended
   community MUST be of the same format.
   ......

To install the BGP SRTE policy at local inetcolor.0 , there are two methods:
1/ Modify the route target to match local BGP Identifier (target:172.16.255.1:x in this article) .
2/ Remove the route target and add community no-advertise .