MPLS-TE RSVP signaling operation

[sergeyrar]

Hi,

I have some misunderstanding (and some contradictory/partial information )  regarding how path signaling is achieved by RSVP.

There is this concept of ERO and RRO, which is a list of the NH addresses RSVP path message has to follow and  addresses traversed by RSVP path message respectively.
Let's say I define the path manually using the LSR loopbacks from head to tail.

If I understand correctly - the ERO should tell the LSRs from Head to Tail to which router should they send the Path message next.
                                         While RRO should tell the LSRs from Tail to Head to which router should they send the RESV message next.



If we follow the example in the attached file -
The RSVP path message is sent from head to tail with the following
ERO-
1: 10.200.254.3 (Brussels LSR)
2: 10.200.254.5 (Berlin LSR) - Tail-end

RRO-
1:10.200.254.2 (Paris) - Head-end

When the path message gets to Brussels LSR it deletes his own address from ERO and adds it to RRO -
ERO:
1: 10.200.254.5 (Berlin LSR)

RRO:
1:10.200.254.3 (Brussels)
2:10.200.254.2 (Paris) - Head-end


Finally at the Tail end we remain only with the RRO:
1:10.200.254.2 (Paris) - Head-end
2:10.200.254.3 (Brussels)
3:10.200.254.2 (Paris) - Head-end


Now all the tail-end has to do is:
1.To allocate a label (which he expects inbound for Tunnel end-point a.b.c.d/32)
2.Send RSVP reserve message telling the label it allocated to the NH address in RRO

Now the question is  -

What if Berlin router has a better cost to reach 10.200.254.3 via a different path ? what if its unicast routing table points it to send the RSVP message from a different interface?

Am I missing something here??




Additional point I have some doubts about -

As with normal IGP, MPLS-TE SPF calculation takes into account only the parameters on Egress links towards the destination.

What if there is congestion on Ingress? RSVP has no way to know about this...




Would be glad for some comments

Thanks,

[wintermute000]

This is the clearest explanation I've found.

https://sites.google.com/site/amitsciscozone/home/important-tips/traffic-engineering/mpls-te-basics

The JNCIS-SP free guides are also pretty good IMO.
I find reading across vendors to be best at firming up your protocol knowledge, too much 'cisco style' info can sometimes lead you down a hole, just seeing the juniper font seems to trigger a refresh in my head LOL.

To answer your first question, my understanding is that the RESV msg follows the ERO (in reverse of course), so the route to the head end IP is irrelevant. Its just after the route to the ERO i.e. next hop.


And I believe for your second question - the ingress BW is irrelevant. A LSP - and a MPLS TE tunnel - is unidirectional. The return traffic would have to follow a LSP path or its own MPLS-TE tunnel. In which case it calculates its own 'egress' bandwidth which is the original tunnels 'ingress'.


Yes, I too am reading MPLS fundamentals, so the pic stood out immediately LOL