Subject: RE: Processing the MPLS TTL

From: Eyad Saheb <[email-masked]>
Date: Mon, 4 Dec 2000 10:59:43 -0500

see below...

-----Original Message-----
From: James R. Leu [mailto:[email-masked]]
Sent: Monday, December 04, 2000 10:49 AM
To: Eyad Saheb
Cc: [email-masked]'
Subject: Re: Processing the MPLS TTL

Hello,

On Mon, Dec 04, 2000 at 10:32:03AM -0500, Eyad Saheb wrote:
> I believe there is a simple answer to this: configuration.  Whether the
> network admin wishes to decrement IP TTL throughout the network, or to
make
> the network appear as one logical hop, it should simply be a matter of
> configuring the LER's (ingress or egress, they're the same box).

Not for a particular LSP.  The LSP setup was requested by ingress,
the ingress also decided between case 1 or 2 when forwarding traffic.  How
does the egress know which case?  Manual configuration isn't acceptable
because the admin may not even know that this LSP was ever going to be
terminated at this node (although that is unlikely, it just proves the
point).

Either we need to make a decisive statement such as "All TE LSPs will use
case 2 and all hop by hop LSPs will use case 1", or signalling needs to
give us a hint of which to use.

---------------
Eyad:
Ah, I'm sorry; I just assumed this would be applicable on the
network as a whole rather than on a per-LSP basis.  In this
case, you are correct: signaling must convey this information.
---------------

> CASE 1: Copy TTL to/from IP header
> CASE 2: Push new TTL at ingress, discard at egress.
> 
> Case 2 is certainly useful when the network wishes to carry non-IP traffic
> (or something that has not been specified yet).

Agreed.  So in that case the the signalling protocol will probably give us
the "hint" we need to make the decision.  This needs to be explicitly
stated in the spec though so diffent vendors at ingress and egress behave
accordingly.

Jim
-- 
James R. Leu

---

From: "Peter Tam" <[email-masked]>
Date: Mon, 4 Dec 2000 21:18:42 -0500

James:

Part of this email must have been snipped, so I don't have the entire thread
of discussion. Any way, my take is that  the TTL is ALWAYS copied from the
MPLS header to the IP header at the egress LSR. In the conventional mode
where it is decremented by 1 at every intermediate hop, it is straight
forward as the total decrement is the number of hops transversed. In the
tunneling or NBMA (e.g. ATM and FR) scenario, it is decremented by 1 at the
ingress LSR and remains constant by intermediate LSRs throughout the domain.
Then, the egress LSR copies it in the same way as it does with the
conventional mode. In other words, the whole tunneling or NBMA domain is
treated as 1 virtual hop. So, there is no inter-operability or agreement
problem between ingress and egress LSRs.

Regards...Peter Tam,
Nortel Networks

	-----Original Message-----
	From:	James R. Leu [SMTP:[email-masked]]
	Sent:	Monday, December 04, 2000 9:49 AM
	To:	Shahram Davari
	Cc:	'francis arts vh624 8492'; [email-masked]; Francis
Arts; Satoru Matsushima; [email-masked]; [email-masked]
	Subject:	Re: Processing the MPLS TTL

	Hello,

	On Mon, Dec 04, 2000 at 04:59:35AM -0800, Shahram Davari wrote:
	> Hi,
	> 
	> I think both methods are allowed. The two scenarios that they
might be used
	> are in Uniform and Tunnel model. In the Uniform model we probably
like to
	> copy the MPLS TTL to the IP TTL, and in Tunnel mode we probably
like to just
	> decrement the IP TTL by one.

	Isn't there a possible interoperabilty problem with this?  The
Ingress and
	Egress have to agree on the same way of handling the TTL? AFAIK none
	of the signling protocols convery this info.

	Jim

	> Yours,
	> -Shahram
	> > From: francis arts vh624 8492 [mailto:[email-masked]]
	> > Sent: Monday, December 04, 2000 1:07 AM
	> > To: [email-masked]
	> > Cc: Francis Arts; Satoru Matsushima; [email-masked];
[email-masked]
	> > Jim,
	> > I agree that section 2.4.3 indeed indicates that "when a 
	> > label is popped, and the
	> > resulting label stack is empty, then the value of the IP TTL 
	> > field SHOULD BE
	> > replaced with the outgoing TTL value".
	> > 
	> > However, the last paragraph of section 2.4.3 also states that 
	> > 'it is recognized
	> > that there may be situations where a network administration 
	> > prefers to decrement
	> > the IPv4 TTL by one as it traverses an MPLS domain, instead 
	> > of decrementing the
	> > IPv4 TTL by the number of LSP hops within the domain."
	> > 
	> > So if one would use the latter approach, the TTL is not meant 
	> > to be copied from
	> > the MPLS header into the IP header in the LSP egress node.
	> > 
	> > Kind regards,
	> > 
	> >     Francis.
	> > 
	-- 
	James R. Leu

---

From: [email-masked]
Date: Wed, 6 Dec 2000 11:56:25 -0000

> Hi Francis,
> Thanks for your reply.
> 
> > Please find included some information on the question you raised:
> > 
> > > Could somebody tell me the behavior of "ingress|egress LSR/LER" on
> > >   this situations?
> > >
> > 
> > ** Ingress LSR:
> > In this case the ingress LSR has to use for the MPLS header a TTL that
> is
> > large enough to reach the egress LSR (that is, the TTL should not expire
> in
> > the middle of the LSP).
> > 
> > ** Egress LSR:
> > At the egress LSR the TTL in the MPLS header is not copied into the IP
> header
> > of the packet. Instead the TTL as is in the IP header is used.
> > 
> > This 'TTL behavior' is -for the TTL aspect- similar to the 'TTL
> behavior' for
> > IP over IP tunnels as defined in section 3.1 of RFC 2003 ('IP within
> IP').
> 
> In this case, it is right if it works as network devices.
> But MPLS-LSP does not work as well as network devices. Thus basically,
> MPLS TTL was set to the value of th IP TTL at the ingress LER, and
> IP TTL was set to the value of MPLS TTL at the egress LSR/LER.
> This is basically situations.
> 
> But Section 2.4.3. "IP-dependent rules" was recognized that 
> there are situations where a network administration prefers to 
> decrement the IPv4 TTL by one as it traverses an MPLS domain.
> As a result, the MPLS domain has two situations. 
> 
> If the MPLS domain really has two situations and be mixed, 
> how can the egress LSR/LER distinguish these two situations?
> 
> I think it is desirable that these situations should be more described
> by "draft-ietf-mpls-label-encaps-08.txt"
> 
I agree completely with the sentiments expressed above......when one creates
an LSP at layer N it is a new layer network in a functional arch sense.  If
one does not accept this then there are both potential layer violation
problems (eg TTL and EXP bits), and functional handling problems (eg
PHP....puts the LSP trail termination point in the wrong place for
server->client adapatation processing, eg OAM and functions like prot-sw
which are dependent on OAM triggers).

The TTL problem are rather obvious and its impact can be easily illustrated
by an example:
A server layer LSP trail at level N can be many label-swapping hops
(=links), but its just a single hop (= 1 link connection) in the client LSP
trail at level N-1.  If we try to predict the server label-swapping hops (to
pre-decrement the TTL) we will have problems, ie when the LSP at level N is
protection switched and the server layer LSP hop count changes.  And
remember, this relationship recurses to level N+1, level N+2, etc for as
many times as there are nested LSPs.  So, as far as I am concerned, TTL only
has any meaning/significance between the LSP source point where it was
generated and the LSP sink point where it is terminated at the level that
the LSP exists.

I have tried to point the above a few times now, and I can see others are
now having the problems I expected because of a lack of functional arch
thinking.

neil