The MPLS WG Archive

["B, Prakash K (Prakash)" <prakashk@lucent.com>]

Eric,
Another question on Hop count. If we continue to disregard tunnels as links,
the number of hierarchial levels in a given AS or a domain must not
influence the final TTL value. Is there something Iam overlooking?

Regards,
Prakash.

-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Wednesday, February 21, 2001 10:01 PM
To: B, Prakash K (Prakash)
Cc: 'mpls@uu.net'
Subject: Re: Hop Count Procedures


Prakash,

    The reason for decrementing TTL is to prevent packets
from endlessly looping.  Hence technologies which do not
support decrementing TTL need to provide another means
for loop prevention or mitigation.  If a technology provides
- for example - a mechanism to prevent loop formation in
LSPs, then the network may gain very little from having
accelerated aging.  In fact, the prevalence of accelerated
aging tends to lead to higher initial TTL values in the
network off-setting at least some of the benefits expected
in networks which use TTL exclusively.

    So there are two questions the network operator has to
ask themselves:

    1)    do they want to treat the tunnel as a link?
and
    2)    can they do this without harming the network?

In some cases, not treating a tunnel as a link can harm the
network.  For example, in the not too distant past, initial
TTL values were set fairly low in some operating systems.
During that time, all it took was for a service provider to
insert one more router in the transit network and suddenly
numerous network destinations were no longer reachable.
In an ideal world, there should not be a detrimental impact
on the service being provided as a result of deliberate
changes in the network infrastructure.

The networking community's response to this was to
increase the default TTL in their operating systems by
as much as a factor of 8 - thus increasing the impact
of looping traffic (originating  from these hosts) on the
network by a factor of between 2 and 4.

However, it is not safe to treat a tunnel as a link if it can
be arbitrarily long (for example - as a result of the fact
that it can have transient looping).  It may also be unsafe
to treat a tunnel as a link if its egress can change without
detection at the ingress - however this can happen in an
L2 network with a real L3 link, so it is not really clear just
how unsafe this is.  I would think it is much less safe in a
network where this can happen fairly often.

So, I would say that you cannot compare the use of TTL
in tunneling across a network technology that does not
support decrementing TTL with the use of TTL in other
network technologies.

--
Eric Gray

You wrote:

> Hello Eric,
> Assume an LSP comprises LSRs Ra, Rb, Rc and Rd with Ra as the ingress and
Rd
> as the eggress nodes and all of them are capable of TTL decrement.
> There is a tunnel1 between Ra and Rb comprising LSRs R1, R2, R3 and R4.
> Similarily, R5-R8 is the tunnel2 connecting Rc and Rd.
> Rb and Rc are direct neighbours. R1 to R8 are ATM LSRs.
>
> >From the above configuration, it follows that Ra is the ingress to
tunnel1
> whose eggress is Rb. Similarily Rc and Rd are the ingress and egress LSRs
of
> tunnel2.
>
> If a packet enters this network, it encounters 12 nodes in all.
>
> Will the TTL of the packet emerging from Rd be (Original TTL - 12) or
should
> it be simply(Original TTL - 4).??
>
> TTL -4 will be the case if the tunnels are of Non TTL decrement type and
one
> of the feature claimed here is the concept of tunnels being oblivious to
the
> end user (possibly an IP cloud connected to Rd).
>
> Do the same rules apply when the tunnels are capable of TTL decrement??
>
> Regards,
> Prakash
>