Subject: RE: New TTL Draft

From: Shahram Davari <[email-masked]>
Date: Fri, 2 Mar 2001 08:45:52 -0800

Hi Eric,

> 1. when a label  is pushed on a packet,  its TTL field is set 
>  to either one
>    less than the iTTL, OR to a configured value;
> 
> 2. when a label is  popped off a packet, the TTL field  of 
> the newly exposed
>    label or IP  header is set to the  minimum of (a) one less 
>  than the iTTL
>    and (b) the existing value of the  field (this rule is 
> needed in order to
>    prevent a TTL from getting longer as a packet travels).
> 

TTL processing mode at the egress of a tunnel MUST be the same TTL processing mode as the ingress of that tunnel. By that I mean if the ingress of a tunnel is processing TTL in Pipe mode, then the egress MUST also process it in Pipe mode. If we observe this rule it is impossible for a TTL to become larger as a packet travels. The only case that TTL may increase is when you process the ingress as Pipe model and the egress as uniform model.

Yours,
-Shahram

---

From: Dan Tappan <[email-masked]>
Date: Fri, 02 Mar 2001 12:04:02 -0500

At 08:45 AM 3/2/2001 -0800, Shahram Davari wrote:
>TTL processing mode at the egress of a tunnel MUST be the same TTL 
>processing mode as the ingress of that tunnel. By that I mean if the 
>ingress of a tunnel is processing TTL in Pipe mode, then the egress MUST 
>also process it in Pipe mode. If we observe this rule it is impossible for 
>a TTL to become larger as a packet travels. The only case that TTL may 
>increase is when you process the ingress as Pipe model and the egress as 
>uniform model.

if you are trying to infer that this rule is not necessary, then I beg to 
differ

1. Even given your rule above, improper configuration (or bugs) at either 
end could cause it to be violated
2. Even given a requirement for agreement at the two ends[*], it is 
possible that a bug at intermediate processing could cause an MPLS TTL to 
end up larger than the IP TTL.

The rule 2 above is simply a requirement for any correctly robust 
implementation.

[*] Note that there are many operational benefits to _not_ requiring 
agreement between the two ends
-- with a mp2p LSP it may be desirable to have different behavior depending 
on where the packet enters the LSP
-- even with a p2p LSP, it may be desirable to have different behavior on a 
per-packet basis. For example, one might want traceroute to show hops of 
the LSP iff the traceroute probe originated on the ELSR.