Subject: RE: Time to live

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 21 Aug 2001 11:27:57 -0700

I think that's a really bad idea.  TTL is there to
protect the network from packets that might be in a loop.
Nesting TTLs to that the outer one is used within the
tunnel while the inner one stays the same could
delay the time the it takes for TTL to protect the packet.

For instance, consider the following topology.

r1 -- r2 -- r3 -- r4 -- r5
       |                 |
      r9 -- r8 -- r7 -- r6

Let's say the path from r3 to r8 is implemented by a
tunnel (in pipe mode).  The packet first hits r2, enters
the tunnel at r3, and then gets to r8. r3-r8 is treated as 
a single hop because the TTL in the IP header is only 
decremented by 1.  In this example the looping packet 
gets to traverse the loop many more times than it 
would have if we were just operating on TTL as specified 
in RFC 3032 (> 60 times versus < 30 times). 

Thus far, the argument in favor of hiding TTL has been 
that it helps hide the network topology and gives the user
a perception of traversing fewer hops.  It seems like
a lame reason because the real measure of performance 
is actually latency.  

Just my $0.02 ;-)
-Anoop

> -----Original Message-----
> From: Ray Qiu [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2001 10:26 AM
> To: Eric W Gray
> Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
> Subject: Re: Time to live
> 
> 
> There is also an option that we don't copy the MPLS TTL back 
> to IP TTL.
> It makes IP think the MPLS LSP is only one hop.
> 
> Thanks,
> Ray
> 
> On Tue, 21 Aug 2001, Eric W Gray wrote:
> 
> > Date: Tue, 21 Aug 2001 13:10:17 -0400
> > From: Eric W Gray <[email-masked]>
> > To: Alexander Marhold <[email-masked]>,
> >      MultiProtocol Label Switching Mailing List <[email-masked]>
> > Subject: Re: Time to live
> >
> > Below, the last sentence was supposed to be "Note that Frame
> > Relay ..."
> >
> > --
> > Eric Gray
> >
> > Eric W Gray wrote:
> >
> > > Alexander,
> > >
> > >     No cigar.  The distinction is not cell verses frame, 
> but rather
> > > whether or not it is possible to incorporate the label in the L2
> > > encapsulation.  Where this is possible, ATM and FR, there is
> > > no TTL capability in the L2 encapsulation.  Not that Frame
> > > Relay is Frame based...
> > >
> > > --
> > > Eric Gray
> > >
> > > You wrote:
> > >
> > > > Hello
> > > > I want to explain the mechanism a little bit more in detail
> > > >
> > > > FRAME based general:
> > > > 1. normally at the ingress LSR the IP-TTL is copied 
> into the TTL-field of
> > > > the label header.
> > > > 2. the label-TTL is decremented at each hop by 1
> > > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > > TTL-exceeded-ICMP message will be sent if possible
> > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > > >
> > > > CELL based general:
> > > > 1. normally at the ingress LSR the IP-TTL is copied 
> into the TTL-field of
> > > > the label header.
> > > > 1a. the ingress LSR to the ATM-MPLS cloud either 
> decrements the TTL by 1
> > > > 1b              or by the amount of ATM_MPLS hops of 
> the LSP ( this he knows from the
> > > > LSP-setup using downstream on demand label allocation 
> and ordered
> > > > lsp-control label setup)
> > > > 2. then the packet is chopped into cells
> > > > 3. the egress reassembles the packet and copies the 
> label ttl back into the
> > > > IP-TTL
> > > >
> > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> > > >
> > > > special features:
> > > > a) on cisco LSRs there is the possibility to disable 
> the copying of the
> > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > > on the egress the smaller of the 2 TTL-values ( label 
> and IP-header) will be
> > > > used for the IP-TTL
> > > > then for traceroute the MPLS cloud looks like a 1-hop 
> (2-hop with PHP)
> > > > network
> > > >
> > > > with best regards
> > > >
> > > > Alexander
> > > >
> > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > > >      __/
> > > >     __/   Dipl.Ing. Alexander Marhold MBA
> > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > > >   __/   Core & IP Services <Senior Consultant>
> > > >  __/   Mobile: ++43-(0)664-16 28 234
> > > > __/   PRO IN http://www.proin.com
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > > > [email-masked]
> > > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: RE: Time to live
> > > >
> > > > It stays the same. The routers only look at the label 
> value not the IP
> > > > header. When the packet leaves MPLS domain then the 
> normal operation would
> > > > apply.
> > > >
> > > > Asim
> > > >
> > > > -----Original Message-----
> > > > From: David Escobar [mailto:[email-masked]]
> > > > Sent: 21 August 2001 17:19
> > > > To: [email-masked]
> > > > Subject: Time to live
> > > >
> > > > Hi;
> > > > What happens to the TTL field in the IP header when a 
> labeled packet goes
> > > > through an LSP? Is it decreased at each router or stay the same?
> >
> 
############################################################################
########################## This email communication may contain CONFIDENTIAL
INFORMATION and is intended only for the use of the intended recipients
identified above.  If you are not the intended recipient of this
communication, you must not use, disclose, distribute, copy or print this
email. If you have received this communication in error, please immediately
notify the sender by reply email, delete the communication and destroy all
copies.
############################################################################
##########################

---

From: Ray Qiu <[email-masked]>
Date: Tue, 21 Aug 2001 11:49:30 -0700 (PDT)

Anoop,

The no-decrement-TTL option making the LSP appear as a one-hop router to
diagnostic tools.  This feature can be turned on per LSP.  So it gives you the flexibility.

Also, you gave us a routing loop example, that should not happen all the
time, right?  :)  So I really don't think it will affect your network
performance.

Thanks,
Ray

On Tue, 21 Aug 2001, Anoop Ghanwani wrote:

> Date: Tue, 21 Aug 2001 11:27:57 -0700
> From: Anoop Ghanwani <[email-masked]>
> To: 'Ray Qiu' <[email-masked]>, Eric W Gray <[email-masked]>
> Cc: Alexander Marhold <[email-masked]>,
> > From: Ray Qiu [ mailto:[email-masked]
> <mailto:[email-masked]> ]
> > > > > __/   PRO IN http://www.proin.com <http://www.proin.com>
> > > > >
> > > > > From: [email-masked] [ mailto:[email-masked]
> <mailto:[email-masked]> ]On Behalf Of
> > > > > From: David Escobar [ mailto:[email-masked]
> <mailto:[email-masked]> ]
> ########################################################################
> ############################## This email communication may contain
> CONFIDENTIAL INFORMATION and is intended only for the use of the
> intended recipients identified above.  If you are not the intended
> recipient of this communication, you must not use, disclose, distribute,
> copy or print this email. If you have received this communication in
> error, please immediately notify the sender by reply email, delete the
> communication and destroy all copies.
> ########################################################################
> ##############################
>
>

---

From: Yousuf Hasan <[email-masked]>
Date: Tue, 21 Aug 2001 12:40:37 -0700

Also, the default is to decrement the MPLS TTL, so as pointed out by Anoop the feature to not decrement MPLS TTL to make the LSP look like a single-hop is a knob only
Thanks

-Yousuf

---

From: Eric Gray <[email-masked]>
Date: Tue, 21 Aug 2001 16:25:07 -0400

Yousuf,

    Actually, this is not a 'no-decrement-TTL' option in the strictest
sense - which should alleviate a lot of concerns.  TTL is decremented
at the ingress LSR (possibly even before it knows it is an ingress LSR)
before a label is pushed onto the stack (creating the stack if necessary).
The as-decremented TTL may then be copied to the new label stack entry
as a starting point for the LSP itself.  Note that this is the expected
behavior, but the actual value used is not important if the egress will
ignore the final TTL value for the LSP when packets are egressed.  In
the 'pipe' analog the as-decremented TTL is then unchanged at the egress
while, in the 'uniform' analog, the as-decremented TTL is over-written by
the further decremented TTL in the encapsulation being popped.

    Note that, as far as TTL is concerned, the only currently defined
behavior is the 'uniform' analog.  People who do not wish to support it
need do (and should do) nothing.  Those people who wish to support the
'pipe' analog will need to define how the ingress and egress can be in
synchronization about how TTL will be processed at the egress.  This can
be done via configuration at each end of every affected LSP, or it may
be accomplished by configuration at the ingress and signaling.  Last time
I heard from Bora and Puneet, their proposal included signaling.

--
Eric Gray

---

From: Ray Qiu <[email-masked]>
Date: Tue, 21 Aug 2001 13:30:09 -0700 (PDT)

Yes.  I think the signaling is preferred if we want to be able to change
the TTL behavior at the egress point.  The ingress needs to know it
should put 255 as the MPLS TTL instead of the real IP TTL.  This prevent
the packets from being dropped in the LSP path.

Thanks,
Ray

On Tue, 21 Aug 2001, Eric Gray wrote:

> Date: Tue, 21 Aug 2001 16:25:07 -0400
> From: Eric Gray <[email-masked]>
> To: Yousuf Hasan <[email-masked]>
> Cc: Ray Qiu <[email-masked]>, Anoop Ghanwani <[email-masked]>,
>      Eric W Gray <[email-masked]>,
>      Alexander Marhold <[email-masked]>,

---

From: Ray Qiu <[email-masked]>
Date: Tue, 21 Aug 2001 11:49:30 -0700 (PDT)

Anoop,

Thanks,
Ray

---

From: Srinivas Reddy <[email-masked]>
Date: Tue, 28 Aug 2001 00:16:34 +0530

hi liwen and all

	sorry for discussing offtopic but i really need it.whare can i get the 
draft-wu-ldp-state-00.txt(i want to know about "Detecting the change in next 
hop"). if any body have better paper on this or algorithm please send me 
thanks in advance
regards
lonka vasu

---

From: David Charlap <[email-masked]>
Date: Mon, 27 Aug 2001 10:23:33 -0400

Srinivas Reddy wrote:
> 
>         sorry for discussing offtopic but i really need it.whare can
> i get the draft-wu-ldp-state-00.txt(i want to know about "Detecting
> the change in next hop"). if any body have better paper on this or
> algorithm please send me thanks in advance

1: The file you named does not exist.  You probably meant:

	draft-wu-mpls-ldp-state-00.txt

2: This draft has been accepted by the working group and has since
   been renamed.  The current version of the file is:

	draft-ietf-mpls-ldp-state-04.txt

3: All current IETF documents (including drafts and RFCs) may be
   downloaded from http://www.ietf.org/.  Follow the links to find
   the document(s) you want.

-- David