IETF DS-TE with RDM
Load mpls.te.base.config.with.ospf.cfg
Configure DS-TE in IETF mode so that the interfaces along the bidirectional path, CSR8-CSR6-XR12-XR11 have 90M CT0 bandwidth available and 10M CT1 bandwidth available. Allow CT0 to use any unused CT1 bandwidth. Disable MPLS-TE on the R8-R9 and R8-R1 links, and on the XR11-R5, XR11-R10 links.
Configure two bidirectional TE tunnels between R8 and XR11 as follows:
One which requests 95M CT0 bandwidth at priority 0
One which requests 8M CT1 bandwidth at priority 7
Answer
Explanation
Using RDM instead of MAM allows BC0 to use any unused BC1 bandwidth. However, BC1 can preempt BC0 LSPs based on priority. So a BC0 LSP will be preempted if a BC1 LSP wants to use this bandwidth based on priority. If the BC0 LSP has priority 0, and the BC1 LSP has priority 7, then preemption will not happen. Also, if both priorities are 0, preemption doesn’t happen. The BC1 priority must be better (not the same).
Note that RDM is the default bc-model. For this reason, you do not need to configure the bc-model on either IOS-XE or IOS-XR. IOS-XE allows you to specify the bc-model, but warns you that this is now a hidden command.
The TE classes work exactly the same as in the previous lab where we used MAM. We can verify the pre-defined TE classes using show mpls traffic-eng ds-te te-class.
We can verify the bc-model by looking at the TED:
Notice above that the max_reservable value is now equal to BC0. It is expected that BC0 encompesses BC0+BC1. In RDM, you don’t configure a separate max reservable value on the interface, as we were able to with MAM.
So if you want 90M for BC0 and 10M for BC1, you could interpret this as BC0 = 100M and BC1 = 10M. Admittedly, this is fairly confusing. It’s difficult to know when you’re referring to only BC0 or BC0 as (BC0+BC1). It is easier if you call BC0 = CT0 + CT1 and BC1 = CT1.
Verification
Let’s signal the first LSP from R8. This uses 95M of BC0 bandwidth. There is only 90M of BC0 bandwidth, so 5M from BC1 will also have to be reserved. This is only possible with RDM.
We then configure a second LSP which requests 8M BC1 bandwidth at priority 7. There is only 5M available, so what will happen?
The answer is that the tunnel cannot be setup. Tun0 uses priority 0, so it cannot be preempted.
If we change this to priority 0, still the LSP will not come up. Both LSPs have priorities of 0/0, so whichever was established first wins.
Only if we change tun0 to priority 7, can we get tun1 to reclaim its BC1 bandwidth. Let’s first shutdown tun1 and change tun0 to priority 7.
Now we’ll change tun1 to priority 0 and no shut it.
Tun1 has successfully re-claimed its BC1 bandwidth, only because its priority was better than BC0. Essentially, you can remember that priority is always used to determine which tunnel is setup. The BC doesn’t play a role in preemption. Also notice that when BC1 bandwidth is reserved, it takes away available bandwidth from BC0. This is because BC0 = BC0+BC1.
Let’s setup the two TE-tunnels on XR11. First we setup Tun0 which uses 95M BC0 bandwidth.
Like we saw with R8, this LSP must borrow 5M from BC1 at priority level 0.
We now setup the worse-priority tun2.
This tunnel cannot be setup.
Only if we change the priorities around, can we can tun1 to preempt tun0.
Now tun1 has preempted tun0:
Last updated
