When true, this makes RSVP-TE address its PATH and PATH-TEAR messages hop-by-hop, meaning each hop sets the IP header's source to its own local outgoing interface address and the destination to the next router's address, rather than addressing all the way to the tunnel's final egress. This addressing mode affects how intermediate routers along the LSP handle these RSVP messages and can matter for interoperability with strict-hop-by-hop implementations from other vendors on a multi-vendor MPLS-TE path. For example, on a multi-vendor LSP where an intermediate router only correctly processes hop-by-hop-addressed RSVP messages, leaving this false on this device could cause that router to mishandle or drop PATH messages, breaking tunnel setup partway through the path.