Summary
Traffic Dictator version 1.3 has been released on 04.02.2025. This article describes changes in the new version.
New feature: PCEP
Path Computation Element Protocol (PCEP) is another method of installing SR-TE policies, in addition to BGP-LU and BGP SR-TE. The advantage of PCEP is that it’s stateful – i.e. PCC (router) reports policy state to PCE (controller).
New config:
router pcep
!
neighbor <ipv4|ipv6>
description <name>
timers <ka> <hold>
passive
shutdown
Example config:
router pcep
!
neighbor 192.168.0.101
!
traffic-eng policies
!
policy R1_R9_EP_STRICT_IPV4
headend 1.1.1.1 topology-id 101
endpoint 9.9.9.9 color 109
binding-sid 15008
priority 4 4
install direct pcep 192.168.0.101
!
candidate-path preference 100
explicit-path R2_R6_R9_STRICT
bandwidth 100 mbps
Verify neighbor status:
TD1#show pcep summary
PCEP summary information
Neighbor V Session ID SRP ID MsgRcvd MsgSent InQ OutQ Up/Down State
192.168.0.101 1 0/1 4 33 30 0 0 0:12:05 SessionUp
TD1#show pcep neighbors
PCEP neighbor is 192.168.0.101, port 35273
PCEP version 1
Last read 0:00:19, last write 0:00:24
Hold time is 120, keepalive interval is 30 seconds
Configured hold time is 120, keepalive interval is 30 seconds
Hold timer is active, time left 0:01:41
Keepalive timer is active, time left 0:00:06
Connect timer is inactive
Idle hold timer is inactive
PCEP state is SessionUp, up for 0:12:26
Number of transitions to SessionUp: 1
Last state was KeepWait
Local session ID: 0, remote session ID: 1
Current SRP ID: 4
Negotiated capabilities:
disjoint, sr-policy
Sent Rcvd
Opens: 1 1
Keepalives: 26 22
PCRequests: 0 0
PCReplies: 0 0
Notifications: 0 0
Errors: 0 0
Closes: 0 0
PMRequests: 0 0
PMReplies: 0 0
PCReports: 0 11
PCUpdates: 2 0
PCInitiates: 1 0
StartTLS: 0 0
Total messages: 30 34
NLRI statistics:
Sent Rcvd
IPv4 SR-TE: 1 0
IPv6 SR-TE: 0 0
IPv4 RSVP-TE: 0 0
Local IP is 192.168.0.1
TTL is 255
Verify policy status and PCEP route:
TD1#show traffic-eng policy R1_R9_EP_STRICT_IPV4
Traffic-eng policy information
Status codes: * valid, > active, r - RSVP-TE, e - EPE only, s - admin down, m - multi-topology
Endpoint codes: * active override
Policy name Headend Endpoint Color/Service loopback Protocol Reserved bandwidth Priority Status/Reason
*> R1_R9_EP_STRICT_IPV4 1.1.1.1 9.9.9.9 109 PCEP/direct 100000000 4/4 Active
TD1#show pcep ipv4 sr-te
PCEP SR-TE routing table information
Status codes: * acked, > up/active, + - inserted, z - zombie
NLRI PLSP-ID Oper status
*>+ [96][16777234][109][9.9.9.9] 1 Active (2)
TD1#show pcep ipv4 sr-te detail
PCEP SR-TE routing table information
PCEP routing table entry for [96][16777234][109][9.9.9.9]
Policy name: R1_R9_EP_STRICT_IPV4
Headend: 1.1.1.1
Endpoint: 9.9.9.9, Color 109
Install peer: 192.168.0.101
Last modified: February 04, 2025 16:00:20
Route acked by PCC, PLSP-ID 1
LSP-ID Oper status
4 Active (2)
Metric type igp, metric 30
Binding SID: 15008
Segment list: [16002, 16009]
PCEP limitations and caveats
PCEP is not a simple protocol like BGP-LU or BGP SR-TE. Standard are vague, different vendors interpret things differently and no implementation supports everything.
TD aims for best compatibility with all vendors but it’s not an easy task. BGP-LU and BGP SR-TE are the recommended protocols to install SR-TE policies due to their simplicity and compatibility out of the box with most vendors.
Only PCE-initiated LSP are supported in first phase
As of 1.3, TD can initiate (PCInitiate) and update (PCUpdate) SR and RSVP LSP, it can also receive PCReports to update LSP status – only for PCE-initiated LSP. Reports for LSP not initiated by TD are ignored.
Support for PCC-initiated LSP is planned in the future.
Only one segment list is supported
Despite almost 50 RFC regulating PCEP as of now, they still haven’t standardized multipath. There is [draft-ietf-pce-multipath] but due to lack of vendor support, TD does not implement multipath yet. However, TD will prefer anycast SID whenever possible, so in some cases multipath can be expressed in one segment list with anycast SID.
Color advertisement in PCEP
The way to advertise SR-TE color via PCEP has not been standardized yet either. Some vendors support [draft-ietf-pce-segment-routing-policy-cp] and TD supports this as well, however it requies SR policy association to be negotiated in PCEP Open messages. Check if it’s negotiated:
TD1#show pcep neighbors | grep -A1 Negotiated
Negotiated capabilities:
disjoint, sr-policy
If it’s not negotiated, TD will not advertise color and depending on PCC implementation, it will be either a colorless policy or a policy with color 4294967295.
LSP status acknowledgement
There is a lot of vagueness about how exactly PCC acknowledges LSP status and what different status codes mean exactly.
TD aims for best compatibility so it keeps track of both PLSP-ID and LSP-ID assigned by PCC. If the PCC advertises multiple LSP-ID for the same LSP, TD prints the “best” status in show commands. Sometimes it’s possible to see multiple transient LSP during route updates (make before break on PCC):
TD1#show pcep ipv4 sr-te detail
PCEP SR-TE routing table information
PCEP routing table entry for [96][16777234][109][9.9.9.9]
Policy name: R1_R9_EP_STRICT_IPV4
Headend: 1.1.1.1
Endpoint: 9.9.9.9, Color 109
Install peer: 192.168.0.101
Last modified: February 04, 2025 16:00:20
Route acked by PCC, PLSP-ID 1
LSP-ID Oper status
3 Active (2)
4 Active (2)
Metric type igp, metric 30
Binding SID: 15008
Segment list: [16002, 16009]
TD1#show pcep ipv4 sr-te detail
PCEP SR-TE routing table information
PCEP routing table entry for [96][16777234][109][9.9.9.9]
Policy name: R1_R9_EP_STRICT_IPV4
Headend: 1.1.1.1
Endpoint: 9.9.9.9, Color 109
Install peer: 192.168.0.101
Last modified: February 04, 2025 16:00:20
Route acked by PCC, PLSP-ID 1
LSP-ID Oper status
4 Active (2)
Metric type igp, metric 30
Binding SID: 15008
Segment list: [16002, 16009]
Some PCC don’t bother with make before break so there will be always just one LSP.
LSP deletion and session reset
According to [RFC8281], in order to delete the LSP, PCE should sends PCInitiate with relevant PLSP-ID, and PLSP-ID 0 informs the PCC to delete all LSP.
Since this could lead to accidental withdrawal of all LSP if just one LSP wasn’t acked by PCC for some reason, TD does not delete LSP for which PCC did not assign PLSP-ID (which could happen due to bug or unsupported feature on PCC). Instead, such LSP are marked as zombies and will rot in the routing table until the PCEP session is shutdown or cleared.
Another problem is that if the PCEP session goes down, existing PCC implementations don’t immediately delete all LSP advertised by dead PCE, like any normal routing protocol would do in this situation. This can not only lead to stale LSP, but also when the session comes up again and PCE advertises the LSP, PCC would reject them with “Symbolic path in use” error.
In order to prevent this, when you shutdown or clear a PCEP session, TD always sends PCInitaite with PLSP-ID 0 to delete all LSP, before closing the session.
New feature: RSVP-TE LSP
In addition to SR-TE and EPE policies, TD can also calculate and advertise RSVP-TE LSP.
Configuration example:
traffic-eng policies
!
policy R1_R9_EP_STRICT_IPV4
headend 1.1.1.1 topology-id 101
endpoint 9.9.9.9 service-loopback 9.9.9.9
rsvp-te
priority 7 7
install direct pcep 192.168.0.101
!
candidate-path preference 100
explicit-path R5_R8_R10
bandwidth 100 mbps
Verify:
TD1#show traffic-eng policy R1_R9_EP_STRICT_IPV4
Traffic-eng policy information
Status codes: * valid, > active, r - RSVP-TE, e - EPE only, s - admin down, m - multi-topology
Endpoint codes: * active override
Policy name Headend Endpoint Color/Service loopback Protocol Reserved bandwidth Priority Status/Reason
r*> R1_R9_EP_STRICT_IPV4 1.1.1.1 9.9.9.9 9.9.9.9 PCEP/direct 100000000 7/7 Active
TD1#show traffic-eng policy R1_R9_EP_STRICT_IPV4 detail
Detailed traffic-eng policy information:
Traffic engineering policy "R1_R9_EP_STRICT_IPV4"
Valid config, Active
This is an RSVP-TE policy
Headend 1.1.1.1, topology-id 101
Endpoint 9.9.9.9, service-loopback 9.9.9.9
Endpoint type: Node, Topology-id: 101, Protocol: isis, Router-id: 0009.0009.0009.00
Setup priority: 7, Hold priority: 7
Reserved bandwidth bps: 100000000
Install direct, protocol pcep, peer 192.168.0.101
Policy index: 18, SR-TE distinguisher: 16777234
Binding-SID: 15008
Candidate paths:
Candidate-path preference 100
Path config valid
Metric: igp
Path-option: explicit
Explicit path name: R5_R8_R10
This path is currently active
Calculation results:
Aggregate metric: 40
Topologies: ['101']
RSVP ERO: ['10.100.3.5', '10.100.9.8', '10.100.12.10', '10.100.21.9']
Policy statistics:
Last config update: 2025-02-04 17:04:58,797
Last recalculation: 2025-02-04 17:04:59.105
Policy calculation took 0 miliseconds5
Policy calculation took 0 miliseconds
Instead of segment list like with SR-TE policies, TD advertises RSVP ERO.
Only PCEP is supported a protocol to install RSVP-TE policies.
Check PCEP route:
TD1#show pcep ipv4 rsvp-te
PCEP RSVP-TE routing table information
Status codes: * acked, > up/active, + - inserted, z - zombie
NLRI PLSP-ID Oper status
*>+ [16777234][9.9.9.9] 3 Active (2)
TD1#show pcep ipv4 rsvp-te detail
PCEP RSVP-TE routing table information
PCEP routing table entry for [16777234][9.9.9.9]
Policy name: R1_R9_EP_STRICT_IPV4
Headend: 1.1.1.1
Endpoint: 9.9.9.9
Install peer: 192.168.0.101
Last modified: February 04, 2025 17:04:59
Route acked by PCC, PLSP-ID 3
LSP-ID Oper status
0 Down (0)
2 Active (2)
Metric type igp, metric 40
RSVP ERO: ['10.100.3.5', '10.100.9.8', '10.100.12.10', '10.100.21.9']
Service loopback for RSVP-TE policies
In the example above, endpoint and service loopback is the same. Since service-loopback is a replacement for color in SR-TE policies to be used with BGP-LU; and the traditional MPLS-TE architecture doesn’t have color-based steering, normally it’s not possible to steer traffic from different services into different RSVP-TE LSP with the same endpoint.
However, with Traffic Dictator, it is possible to configure a service loopback to be different from endpoint, so that the service loopback is not advertised into IGP. Some RSVP implementations allow to singal the LSP towards the endpoint that is not advertised in IGP, in this case it’s possible to use an architecture similar to color-only steering, but with traditional MPLS-TE.
Caveats and limitations
All the caveats related to PCEP SR-TE LSP, also apply to RSVP-TE LSP. In addition to that:
RSVP-TE LSP are always advertised with bandwidth 0
TD keeps internal database of bandwidth for all SR-TE, RSVP-TE and EPE policies. Provisioning RSVP-TE LSP with bandwidth would lead to a lot of churn in IGP and possible double-reservations.
RSVP-TE LSP with EPE endpoint are not supported
Since RSVP-TE is stateful, it’s not possible to just add one extra lable like with SR-TE. But it’s possible to configure 2 separate policies: RSVP-TE and EPE-only resolving via RSVP-TE.
Bug fixes and improvements
1. API idempotency (bug #32). Starting from 1.3, HTTP API is idempotent and the same request sent multiple times will give the same result.
2. API atomic config support (bug #33). Starting from 1.3, HTTP API operations are atomic and the entire request will either succeed or fail.
3. API scale improvements (bug #34). In 1.3, API has been improved to support larger configs. Current tested scale is up to 20k SR-TE policies.
4. BGP FSM: If neighbor has very small ConnectRetryTimer, TD keeps resetting IdleHoldTimer so it never expires (bug #35). Fixed in 1.3, now IdleHoldTimer never resets when BGP state is Idle.
5. 1-hop BGP-LU policies sent with an empty label stack (bug #36). When BGP-LU is used as a protocol to install SR-TE policies, TD checks if the first SID in the segment list belongs to the router directly connected to the policy headend. If yes, TD removes first label because BGP-LU uses BGP nexthop to resolve first hop (unlike BGP SR-TE which uses first label). When a policy is just one hop, this behaviour results in an empty label stack being sent.
Fixed in 1.3, now label 3 (imp-null) is sent instead of an empty label stack.
Download
You can download the new version of Traffic Dictator from the Downloads page.