Summary
Traffic Dictator version 1.6 has been released on 07.07.2025. This article describes changes in the new version.
PCEP improvements
TD 1.3 introduced PCEP as one of the protocols for SR-TE policy installation. 1.6 comes with a number of bug fixes and improvements that improve PCEP interoperability with different router implementations, especially in dual-PCE redundancy scenarios.
Delegation and sync
Now there is correct handling of PCEP delegation/de-delegation and sync after session establishment or reset. This required multiple changes in PCEP FSM:
- When PCEP session comes up, PCInit/PCUpdate are not sent right away, but delayed until End-of-Sync marker (special PCReport with all fields set to 0, as per RFC8231 section 5.6) is received + additional 5 seconds because some implementations (e.g. Cisco and IP Infusion) send additional PCReports with LSP status update after End-of-Sync marker
- During SYNC phase, PCReports are correlated with LSP by their Symbolic Path Name
- After End-of-Sync + 5 seconds, TD sends PCUpdate for LSP delegated to us + PCInit for LSP that were not present in PCReport
Init-delay timer
New configuration:
router pcep init-delay <0-60>
The default value is 0, allowed values are from 0 to 60 seconds. Whenever TD needs to send PCInitiate, it will be delayed by [init-delay] number of seconds. The reason for this is dual PCE redundancy. RFC8231 section 5.7 describes LSP delegation by PCC, and TD now supports all of that; so only the PCE to which LSP is delegated will be updating it. However, during dual PCE redundancy, 2 PCE can simultaneously send PCInitiate for a new LSP and that can cause errors on PCC side. Therefore, it is recommended to set init-delay to 5-10 seconds on the backup PCE.
One exception when the init-delay timer is not applicable is Juniper-style redundancy, because Juniper doesn’t redelegate but just removes LSP when the primary PCE goes down. Therefore, upon receiving PCReport with R flag and all fields set to 0 but on PCE side the LSP is still active, we just send immediate PCInitiate disregarding the init-delay timer. Cisco and IP infusion redelegate LSP to the second PCE when the primary PCE goes down.
PCE redundancy examples
TD now supports 2 different PCE redundancy scenarios. How it will work for you, depend on PCC implementation, no additional configuration on TD is required.
Cisco-style redundancy (redelegation)
This is how it’s implemented on Cisco IOS-XR and IP Infusion OcNOS
Primary PCE (TD1) sends PCInit, PCC (R1) delegates the LSP to TD1 and also informs TD2 about it, so that TD2 doesn’t need to initiate the same LSP and can see the LSP status. When R1 session with TD1 goes down, it redelegates the LSP to TD2 and TD2 can now update the LSP. If TD1 comes back up, R1 can redelegate the LSP to TD1 again.
Juniper-style redundancy (removal and re-init)
The LSP initiation works the same way as in the previous example, but when Juniper session with TD1 goes down, it deletes the LSP and sends PCReport with R (remove) flag set to TD2. Upon receiving such a report (while the LSP status on TD is still active), TD2 sends immediate PCInit (regardless of init-delay config) for the same LSP, and now R1 delegates this LSP to TD2. If TD1 comes back up, the LSP will stay delegated to TD2.
Withdraw timer
There is a static 5 second timer set for the situation when TD needs to withdraw and init the LSP with the same name again – for example, endpoint change (which from PCEP perspective is a different LSP, but reusing the Symbolic path name). Another example is Binding SID change – PCC implementations don’t like PCUpdate with another BSID, so for better compatibility TD withdraws and sends a new PCInitiate.
The timer is introduced for better compatibility, because if PCInitiate for the same Symbolic path name is sent too quickly, some PCC implementations complain and drop the session.
PCEP policies with service loopback
Previously, only RSVP-TE policies with PCEP could be configured with a service loopback. SR-TE policies required color. Now this requirement is relaxed and PCEP SR-TE policies can be configured with service loopback. Justifications:
- Compatibility with PCC implementations that don’t support PCEP association groups and therefore cannot understand SR-TE color
- Easier migration from RSVP-TE to SR-TE
- Just more options for SR-TE design, including mixing PCEP and BGP-LU policies
Binding SID is advertised per RFC9604
Previously, TD advertised BSID in PCEP using a temporary TLV 65505. Since this is now standardized, now TD advertises BSID in the TE-PATH-BINDING TLV #55.
Binding SID no longer mandatory for PCEP and BGP-SRTE
Previously, Binding SID configuration mandatory for SR-TE policies with color (i.e. advertised via PCEP or BGP-SRTE). Now BSID is optional.
Change of PCEP status codes display in CLI
For better user experience, “show pcep …” CLI outputs have new status codes now. E.g. on primary PCE (where the LSP have been delegated by PCC):
TD1#show pcep ipv4 sr-te
PCEP SR-TE routing table information
Status codes: * up/active, > delegated to us, p pcc-initiated, z zombie
NLRI PLSP-ID Oper status
*> [16777234][109][9.9.9.9] 1 Active (2)
*> [16777222][7][0.0.0.0] 2 Active (2)
*> [16777220][4][10.100.20.105] 3 Active (2)
On secondary PCE:
TD2#show pcep ipv4 sr-te
PCEP SR-TE routing table information
Status codes: * up/active, > delegated to us, p pcc-initiated, z zombie
NLRI PLSP-ID Oper status
* [16777234][109][9.9.9.9] 1 Active (2)
* [16777222][7][0.0.0.0] 2 Active (2)
* [16777220][4][10.100.20.105] 3 Active (2)
PCEP bug fixes
Aside from the aforementioned improvements, there are a few PCEP bug fixes in 1.6.
- PCEP capabilities not clearing when session goes down (bug #51). Now capabilities are removed and re-negotiated again during PCEP Open exchange.
- Correct parsing of PCEP message with reports for multiple LSP (bug #39). Some implementations send a separate PCEP message for each LSP, but some send one report with a list of LSP. This is allowed by RFC8231 section 6.1, so now this is parsed correctly.
Multi-domain policy improvements
TD supports multi-domain policies starting from 1.0, but 1.6 introduces some improvements.
Policies starting and ending in EPE topology
Consider the topology:
Earlier, it was possible to build a policy from R1 to R5, using a mix of IGP topology; and BGP Peer SID advertised by R2 and R3.
Starting from 1.6, it is also possible to build a policy from R2 to R4 – i.e. starting and ending with BGP links (EPE topology from TD perspective). Likewise, it is possible to build policies R1-R4 and R2-R5.
Limitation: if a policy ends by a BGP-EPE link, TD assumes this is an EPE policy and always sets Explicit Null Label Policy (ENLP) to “none”.
Proxy remote router-id for BGP-LU EPE routes for multi-domain policies
BGP Peer SID advertises both local and remote router-id. Therefore, when building a multi-domain policy, TD can use the remote router-id to look either for the next IGP topology, or next BGP Peer SID.
If the router doesn’t support BGP Peer SID, but can generate BGP-LU EPE routes, there is a problem that BGP-LU doesn’t include remote router-id.
In order to workaround this, it is now possible to advertise a special value large community to TD, where:
- ASN – must be the same as router ASN
- Local data1 – must be set to 1
- Local data2 – must be set to the desired remote router-id
E.g. in the topology above, R2 would advertise a BGP-LU route with a large community with Local data2 set to the router-id of R3.
Route-map config example on Arista EOS:
route-map TEST permit 10 set large-community 65002:1:84215045
84215045 is 5.5.5.5 converted to decimal.
Output on TD shows that remote router-id for SR-TE purposes is changed from 4.4.4.4 (BGP peer router-id) to 5.5.5.5 (advertised in community).
TD#sh bgp ipv4 labeled-unicast 172.16.0.11/32
BGP-LS routing table information
Router identifier 111.111.111.111, local AS number 65001
BGP routing table entry for 172.16.0.11/32
Label stack: [100000]
Paths: 1 available, best #1
Last modified: July 06, 2025 19:57:06
65002
192.168.123.104 from 192.168.123.104 (4.4.4.4 - override to 5.5.5.5)
Origin incomplete, metric 0, localpref 100, weight 0, valid, external, best
Other bug fixes and improvements
- ISIS pseudonode bw not returned correctly (bug #47). When an IS-IS multi-access link went down and the pseudonode disappeared from the LSDB, bandwidth reservations going through that pseudonode were not returned correctly.
- TTL didn’t change to 255 if BGP peer config changed from eBGP to iBGP (bug #52). This only happened during dynamic config change from eBGP to iBGP.
- Support for BGP ORIGINATOR_ID and CLUSTER_LIST (bug #53). This enhancement supports the 2 BGP attributes used for route reflection. Also, TD will now discard incoming BGP updates with out router ID in CLUSTER_LIST.
- Redundancy server sometimes sends old config during full sync (bug #56). This happened if a HA pair comes up, does initial config sync, then no config changes are ever made on either of peers and the primary peer reboots. Then the backup peer would send the old config.
- Race condition during full config sync on redundancy session (bug #57).
Download
You can pull the latest TD version from Docker Hub:
sudo docker pull vegvisirsystems/td:latest
Alternatively, download the new version of Traffic Dictator from the Downloads page.