After adding more links into the AE bundle, it looks that the RSVP interface bandwidth hasn't been updated since then.

The customer's AE boundl holds 20 100G links as below:

nobody@noname-RE0> show interfaces terse | grep ae11 

et-3/0/0.0 up up aenet --> ae11.0

et-3/0/1.0 up up aenet --> ae11.0

et-3/0/2.0 up up aenet --> ae11.0

et-3/0/3.0 up up aenet --> ae11.0

et-3/0/4.0 up up aenet --> ae11.0

et-3/0/5.0 up up aenet --> ae11.0

et-3/0/7.0 up up aenet --> ae11.0

et-3/0/9.0 up up aenet --> ae11.0

et-3/0/10.0 up up aenet --> ae11.0

et-3/0/11.0 up up aenet --> ae11.0

et-3/0/22.0 up up aenet --> ae11.0

et-3/0/23.0 up up aenet --> ae11.0

et-3/0/28.0 up up aenet --> ae11.0

et-3/0/29.0 up up aenet --> ae11.0

et-5/0/18.0 up up aenet --> ae11.0

et-5/0/23.0 up up aenet --> ae11.0

et-5/0/24.0 up up aenet --> ae11.0

et-5/0/25.0 up up aenet --> ae11.0

et-5/0/26.0 up up aenet --> ae11.0

et-5/0/27.0 up up aenet --> ae11.0

ae11 up up

ae11.0 up up inet 68.1.0.112/31

But the physical interface's bandwidth shows up differently compared to logical interface's speed.

nobody@noname-RE0> show interfaces ae11 extensive 

Physical interface: ae11, Enabled, Physical link is Up

Interface index: 134, SNMP ifIndex: 675, Generation: 137

Link-level type: Ethernet, MTU: 9100, Speed: 2000Gbps, BPDU Error: None, Ethernet-Switching Error: None, MAC-REWRITE Error: None, Loopback: Disabled,

<snipped>

Logical interface ae11.0 (Index 70) (SNMP ifIndex 713) (Generation 135)

Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2

Bandwidth: 1600Gbps

Statistics Packets pps Bytes bps

Bundle:

Input : 128521972203 56 65027480594360 33008

Output: 722023199768 0 929012558554354 0

Adaptive Statistics:

Adaptive Adjusts: 0

Adaptive Scans : 0

Adaptive Updates: 0

Link:

<snipped>

Protocol inet, MTU: 9086

Max nh cache: 100000, New hold nh limit: 100000, Curr nh cnt: 1, Curr new hold cnt: 0, NH drop cnt: 0

Generation: 157, Route table: 0

Flags: Sendbcast-pkt-to-re

Addresses, Flags: Is-Preferred Is-Primary

Destination: 192.168.0.112/31, Local: 192.168.0.112, Broadcast: Unspecified, Generation: 143

Protocol iso, MTU: 9083, Generation: 158, Route table: 0

Protocol mpls, MTU: 9066, Maximum labels: 5, Generation: 159, Route table: 0

Protocol multiservice, MTU: Unlimited, Generation: 160, Route table: 0

What's more, the rsvp interface keeps showing BW with the logical interface's speed.

           nobody@noname-RE0> show rsvp interface | grep "interface|ae11"

RSVP interface: 8 active
Interface State resv iption BW BW BW mark
ae11.0 Up 2 92% 1.6Tbps 1.472Tbps 0bps 1.13521Tbp

This issue hits PR1649958: "The user-defined speed does not take effect on the AE interface in certain scenarios on Junos platforms"

Root Cause:
On the platforms supporting GRES (Graceful Routing Engine Switchover), the bandwidth flag on the backup RE (Routing Engine) for the AE interfaces is set unconditionally, hence the bandwidth is struck at a value despite not being set by the user statically. When GRES is performed followed by link delete/add for the AE interface, the interface would get stuck with the bandwidth and gets synced with the backup RE. There can be seen partial service impact in the case of the RSVP (Resource Reservation Protocol) .
 

Workaround:

After deployment workaround below, this issue can be solved temporarily, but the final solution should be Junos upgrade.

------------------------------------------
edit
set interfaces aeX.0 bandwidth <bandwidth- value>
commit full
exit
------------------------------------------
edit
delete interfaces aeX.0 bandwidth
commit full
exit
------------------------------------------