user65653: Both in the Basic of Lightning Technology (BOLT) documents, and in the specification of lnd, there is a different treatment for the last channel in a route. In BOLT#2 it refers to a variable min_final_cltv_expiry:

min_final_cltv_expiry is the minimum difference between HTLC CLTV timeout and the current
  block height, for the terminal case (C).

This value is 9, as opposed to 144 for cltv_expiry_delta.
This is most likely related with the output of a route when querying lnd, for example, suppose the route Alice -> Bob -> Carol -> Dave, routed from Alice:
the output is:
$> lncli-alice queryroutes --dest=<Carol_pubkey> --amt=5 --num_max_routes=1
total_time_lock: 1443640
total_fees: 1
total_amt: 6
hops {
  chan_id: <id_chan_alice_bob>
  chan_capacity: <cap>
  amt_to_forward: 6
  expiry: 1443610
  amt_to_forward_msat: 6000
  fee_msat: 1
}
hops {
  chan_id: <id_chan_bob_carol>
  chan_capacity: <cap>
  amt_to_forward: 5
  fee: 1
  expiry: 1443466
  amt_to_forward_msat: 5000
  fee_msat: 1000
}
hops {
  chan_id: <id_chan_carol_dave>
  chan_capacity: <cap>
  amt_to_forward: 5
  expiry: 1443466
  amt_to_forward_msat: 5000
}
total_fees_msat: 1001
total_amt_msat: 6001

Notice the last two hops have the same expiry value. Why is the last hop different with regard to the expiry?

user65653: After some searching through the BOLT documents and talking with the lnd slack community, I found an answer:

B->C. If B were to send 4,999,999 millisatoshi directly to C, it would
  neither charge itself a fee nor add its own cltv_expiry_delta, so it
  would use C's requested min_final_cltv_expiry of 9. Presumably it
  would also add a shadow route to give an extra CLTV of 42.
  Additionally, it could add extra CLTV deltas at other hops, as these
  values represent a minimum, but chooses not to do so here, for the
  sake of simplicity:

Also, although cltv_expiry_delta is default to 9 in BOLT, in lnd they use 144, but without checking for the final hop. That is, they do not add the final_cltv_expiry because they have already a big cltv_expiry (I presume). Olaoluwa said in the slack 
that they plan to reduce the value of cltv_expiry_delta to get closer to the default value listed in BOLT. However, if they do this, I hope they take care of adding the additional cltv_expiry_delta, as it will be important to add in this case. For an example of what I mean, check the above-linked link for BOLT #007

65653: <p>Both in the Basic of Lightning Technology (<a href="https://github.com/lightningnetwork/lightning-rfc" rel="noreferrer">BOLT</a>) documents, and in the specification of lnd, there is a different treatment for the last channel in a route. In <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md" rel="noreferrer">BOLT#2</a> it refers to a variable <code>min_final_cltv_expiry</code>:</p>

<blockquote>
  <p><code>min_final_cltv_expiry</code> is the minimum difference between HTLC CLTV timeout and the current
  block height, for the terminal case (C).</p>
</blockquote>

<p>This value is 9, as opposed to 144 for <code>cltv_expiry_delta</code>.</p>

<p>This is most likely related with the output of a route when querying lnd, for example, suppose the route Alice -> Bob -> Carol -> Dave, routed from Alice:
the output is:</p>

<pre><code>$&gt; lncli-alice queryroutes --dest=&lt;Carol_pubkey&gt; --amt=5 --num_max_routes=1
total_time_lock: 1443640
total_fees: 1
total_amt: 6
hops {
  chan_id: &lt;id_chan_alice_bob&gt;
  chan_capacity: &lt;cap&gt;
  amt_to_forward: 6
  expiry: 1443610
  amt_to_forward_msat: 6000
  fee_msat: 1
}
hops {
  chan_id: &lt;id_chan_bob_carol&gt;
  chan_capacity: &lt;cap&gt;
  amt_to_forward: 5
  fee: 1
  expiry: 1443466
  amt_to_forward_msat: 5000
  fee_msat: 1000
}
hops {
  chan_id: &lt;id_chan_carol_dave&gt;
  chan_capacity: &lt;cap&gt;
  amt_to_forward: 5
  expiry: 1443466
  amt_to_forward_msat: 5000
}
total_fees_msat: 1001
total_amt_msat: 6001
</code></pre>

<p>Notice the last two hops have the same <code>expiry</code> value. Why is the last hop different with regard to the expiry?</p>
 65653: <p>After some searching through the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md" rel="noreferrer">BOLT</a> documents and talking with the lnd <a href="https://lightningcommunity.slack.com/" rel="noreferrer">slack</a> community, I found an answer:</p>

<blockquote>
  <p>B->C. If B were to send 4,999,999 millisatoshi directly to C, it would
  neither charge itself a fee nor add its own cltv_expiry_delta, so it
  would use C's requested min_final_cltv_expiry of 9. Presumably it
  would also add a shadow route to give an extra CLTV of 42.
  Additionally, it could add extra CLTV deltas at other hops, as these
  values represent a minimum, but chooses not to do so here, for the
  sake of simplicity:</p>
</blockquote>

<p>Also, although <code>cltv_expiry_delta</code> is default to 9 in BOLT, in <code>lnd</code> they use 144, but without checking for the final hop. That is, they do not add the <code>final_cltv_expiry</code> because they have already a big <code>cltv_expiry</code> (I presume). Olaoluwa said in the slack 
that they plan to reduce the value of <code>cltv_expiry_delta</code> to get closer to the default value listed in BOLT. However, if they do this, I hope they take care of adding the additional <code>cltv_expiry_delta</code>, as it will be important to add in this case. For an example of what I mean, check the above-linked link for BOLT #007</p>
