That's correct. Generally TE tunnel is either dynamic or explicitly defined. In dynamic path, you just need to configure tunnel destination's ip address, ignoring in between hops in the paths whereas in explicitly defined path you need to define/mention all the hopes involved in the paths to the destination.
However, if you want to have automatic path calculations and automatic rerouting of IP traffic onto MPLS TE paths, you have to use dynamic tunnel with OSPF or IS-IS. Here link state protocol (IS-IS or OSPF) is used with enhanced link state advertisements to track network capacity and to ensure that the tunnel does not create a routing loop. The actual signaling for dynamic tunnel establishment is based on RSVP, which acts to reserve bandwidth on a link.
Also, in some cases, MPLS-TE tunnel can be configured to use multiple paths (explicit as well as dynamic) from the source to the destination so that it can choose the path it needs in the order of preference.
So now to answer your questions:
You don't require IGP if you are using explicit path. Although I haven't tried configuring explicit path alone in lab/real world, but considering RSVP's function, I guess that you don't require RSVP in the case where you are using explicit path only.
Also you are right when you say that IGP(OSPF or ISIS) is required in order to make dynamic path work as these two protocol(OSPF and IS-IS) have been provided with extensions to enable their use in an MPLS TE environment to propagate information pertaining to resource availability and in dynamic LSP path selection.
To give you real world scenario, in our SP network design, we are using dynamic tunnel with OSPF as IGP and no explicit path at all.
MPLS TE config must be enabled under IGP config irrespective of explicit or dynamic paths. By enabling MPLS TE, will enable RSVP signalling across the routers from source to destination.
Without enabling TE under IGP, RSVP will not distribute the labelling info from destination to source (either in explicit and dynamic)...because in our network with explicit path, TE tunnel comes up only when TE is configured under IGP...
When I said you don't require IGP incase of explicit path, I should have mentioned feature called 'Verbatim Path Support'(see the link below). With the support of this feature, it is possible to have explicit path in the TE network without configuring link state IGP.When this feature is enabled, the IP explicit path is not checked against the TE topology database.
I would like to confirm.. With this Verbatim Path Support Feature, i can even run TE tunnel betwen two different OSPF area's (Inter-Area TE tunnel) cos we are not going to configure any IGP extensions with MPLS TE with Explicit paths rite.. Only thing is I would upgrade the IOS of my PE to support Verbatim Path Support (as part of OSPF sub-area)...
You still need RSVP-TE support on the mid-nodes even if you are using verbatim feature. Verbatim feature will cause head-end router perform regular SPF algorithm rather than cSPF. Since head-end will be unable to perform cSPF it will rely on explicit path (verbatim), which will be put it in ERO object in RSVP Path messages, so again RSVP-TE support is still required even if you are using non-link state protocol.
One more comment. Even through cSPF is not performed on a head-end, each mid-node still verifies (locally on the device itself) that outbound interface for RSVP Path message is able to provide bandwidth reservation required, so you still have to configure all RSVP bandwidth commands even when using verbatim feature...
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...