Subject: Re: New TTL Draft

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Mar 2001 15:35:14 -0500

From the draft:

>   This document describes TTL processing in hierarchical MPLS 
>   networks. We believe that this document adds details that have not 
>   been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods 
>   presented in this document complement [MPLS-DS].  

I think  it would be helpful for  the draft authors to  say explicitly where
this draft:

1. corrects errors in the RFCs

2. modifies the functionality specified in the RFCS

3. adds new functionality not specified in the RFCs

4. adds details to clarify what is specified in the RFCs. 

That  is, let's  try to  make sure  that we  all agree  about  what changes/
additions are being proposed, and why. 

It is true that the RFCs are not very clear about the way to handle the case
where one doesn't  want to percolate the TTL through  the label stack ("pipe
model"?). 

Whether the "pipe model" and the "uniform model" always (or ever) need to be
distinguished through signalling is  another matter.  Is the assumption that
a service provider might make a different decision for every individual LSP? 
(In the case  of "ordinary" LDP, I think this is  somewhat unlikely, and the
signalling unnecessary.)

---

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Mar 2001 16:20:19 -0500

Consider the following way of handling TTL at the push/pop points:

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).

Then  the  pipe  model  can  be  provided by  having  a  sufficiently  large
configured value (e.g., 255) in  step 1 (given certain assumptions about the
length of the LSP). 

It's kind of heuristic, but it  usually works, it doesn't complicate the pop
processing any  more than  is absolutely necessary,  and it doesn't  rely on
signalling (only the head end needs to know the model). 

I believe there are certain implementations that work this way.

---

From: Sachin Doshi <[email-masked]>
Date: Fri, 02 Mar 2001 18:43:35 +0530

Hi Bora,
   Some query's :

1. In section 2.4 u have covered MPLS routed packets? What about packets
which come to a LSR, but which are not directed to him (i mean the
MAC address of the packet was not this LSR's address. I think it is a
valid scenerio). Should TTL be decremented for such packets?

2. In your later discussions, you said that you would like to keep a
value "N", by which the TTL should be decremented. Will it not be a
problem with MCAST traffic, for which we may like to keep a smaller
TTL value, so that it should not go out of an organization. Because of
this multiple TTL decrement it will not reach to the intended
recepients.

regards.
   sachin

Bora Akyol wrote:

> Note that we (Puneet and I) just posted an Internet Draft on TTL
> handling in hierarchical MPLS networks.
>
> The internet draft is titled: draft-agarwal-mpls-ttl-00.txt
>
> http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt
>
> We welcome any comments,
>
> Bora Akyol

---

From: Eric Gray <[email-masked]>
Date: Fri, 02 Mar 2001 11:43:39 -0500

Sachin,

    Routers only decrement TTL for packets they route.
    Bridges never decrement TTL.

    Decrementing by a value other than one would be a
network administrator configured value.  In all likelyhood,
the value used for TTL in multicast traffic within an
enterprise would also be a network administrator configured
value.  There should be no issue with unwanted TTL expiry
of packets within an enterprise.

    Also, it might be desirable for the network adminsitrator
to deliberately configure a TTL decrement other than one,
at border routers (for example), to ensure that multicast
packets do not escape.  However, there are other ways to
do this.

--
Eric Gray

---

From: Bora Akyol <[email-masked]>
Date: Fri, 2 Mar 2001 09:48:00 -0800

>valid scenerio). Should TTL be decremented for such packets?

If this is a bridge then the box should not care about this, if this 
is a router and it received a packet that was intented for it, this 
is an error.

>this multiple TTL decrement it will not reach to the intended

N is configurable.

Bora

---

From: Sachin Doshi <[email-masked]>
Date: Fri, 02 Mar 2001 23:56:02 +0530

> is a router and it received a packet that was intented for it, this

should it not be was "not"

> is an error.

To support that this may not be a invalid scenerio here is an example:

LDP says that after becoming alive LSR sends periodic hello messages to
peers. Suppose there was a configuration, where R1,R2 and R3 were on the
same LAN. R1 and R3 are connected through R2. (R1 and R3 are MPLS aware, but
R2 is not). So for all LSP's between R1 and R3, R2 acts as a switch. Now i
replace R2 with an MPLS aware router. During the time it negotiates with R1
and R3 through LDP, it will still get packets which were directed from R1 to
R3 and which will be carrying R3's MAC address. For this period what should
R2 do?
should it switch ackets based on the L2 address or should it look for the
MPLS label and try to switch the packets?

regards,
    sachin