MPLS-TE FA

[wintermute000]

Trying to understand MPLS-TE forwarding adjacency better. If MPLS-TE FA advertises the TE tunnels into the IGP, then how does it stop recursion issues e.g. for the loopbacks used as RSVP target IPs? Other routers in the IGP going to get their RSVP signalling hijacked and go through the tunnel?!?!


I can't find any references describing any mechanisms to say exclude loopbacks or similar. I CAN find some snippets re: CSPF ignoring the advertisements but I can't recall exactly where.


I'm thinking that for example if there is strict ERO then the RSVP PATH hop by hop is always going to be directly connected so that fixes that - but what about loose (unless CSPF ignores any forwarding adjacency distributed 'routes')


Is it because once the RSVP set up, regardless of strict or loose, all routers in the path have the exact path recorded so the refresh is going to be hop by hop anyway (hence directly connected hence no possibility of incorrect recursion)?  But that doesn't account for reoptimisation and probably other things....


I've gone through all my MPLS textbooks (MPLS fundamentals, Definitive MPLS Designs, MPLS in the SDN era, MPLS and VPN Arch v2....), dived into the Cisco TE white papers, IOS/IOS-XR config guides, JunOS config guides, heck even skimmed alcatel doco, nobody talks about recursion caused by MPLS-TE forwarding adjacency - in fact they don't even talk about it with autoroute/IGP shortcut which I guess I am asking the same question about as well (if the headend router wants to signal another RSVP tunnel to a destination beyond something its got a shortcut to?)

[burnyd]

I dont think I am following you here.  Like I think you are referring to the auto tunnel and advertising that /32 instead of doing source / dest of the tunnel PE where you are trying to land the tunnel upon?

Can you draw a picture of some sort so others can follow along?

[wintermute000]

Simple, I'm talking about the MPLS-TE FA 'routes' hijacking the path for RSVP-TE signalling leading to the classic tunnel recursion issue or at least suboptimal RSVP behaviour.

e.g.

R1-R2-R3-R4-R5-R6

RSVP Tunnel from R2 to R5, turn on FA
Now if R1 wants a tunnel somewhere behind R5, it will see the best path through the RSVP tunnel? And you will unwittingly tunnel RSVP in RSVP? (I know this is a thing you can explicitly do)
Even worse, if R3 wants a tunnel to R6, it might see the best path as via R2?

However I found reference in Alcatel doco that CSPF ignores the MPLS-TE FA routes due to lack of TE information attached to them. And a random comment on reddit, FWIW. And obviously if its fully explicit ERO then no issue either as you've dictated hop by hop behaviour. Would be nice though to find the Cisco or Juniper reference that states this explicitly.

[sergeyrar]

We had this issue with our router.
RSVP signaling was routed inside the tunnel it has created.
RSVP signaling should be treated differently from other traffic and shouldn't have label information imposed.

[wintermute000]

how did you overcome it? All my research so far indicates that RSVP CSPF algo ignores MPLS-TE FA routes.

[sergeyrar]

It was a bug.
RSVP control is routed differentely than normal traffic.
If there is an explicit path then its sent hop by hop according to the list of routes -without labels, and each RSVP enabled router checks if its in the path and allocates resourses accordingly.
For CSPF its just sent according to the IGP best path, and again without label information .
In both cases...after the tunnel has been established each router on the tunnel path has to somehow know that these RSVP packets are destined to the CPU, since they're sent without label information with a destination IP of the tail-end.
For this there is a special flag (which I forgot its name) which tells the router to check this RSVP packet and process it(in case RSVP is enabled)

Hope this helps.

[wintermute000]

Cheers for confirming

[wintermute000]

Clarification time:
- I'm fairly sure you're talking about the RA flag re: CPU punt
- so the PATH and RESV messages never use labels and are always unlabelled, is that what you're saying? That makes sense thinking about it, if it had a label then hop by hop processing can't possibly occur?
- I thought the CSPF algorithm during the SPF tree building ignores RSVP info, is this in addition to the above point?

[sergeyrar]

1. Yes that's the one!
2. If they had labels on them, then they would be just routed according to LFIB and that would cause the TE-tunnel to constantly flap, since transit RSVP LSRs wouldn't be able to process these packets.
3. About that i'm not 100% sure..it does ignore if you only use CSPF without any explicit constraint definitions. But if you use some conatrains then it does take them into account while forming the tunnel.

[wintermute000]

cheers and good point re: 2