Subject: RE: New TTL Draft

From: Puneet Agarwal <[email-masked]>
Date: Thu, 1 Mar 2001 20:52:11 -0800

Hi Eric,

Please see my comments inline.

-Puneet

>
>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;

(i) It is unclear from the description if the label/ip-packet on which you
pushed the new label(s) had its TTL modified to one less than iTTL. I
believe that the encapsulated header ttl should be set to one less than iTTL
for your case 2(b) to work and not cause a packet to potentially loop
indefinitely.
>
>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). 

(ii) The egress could choose to treat every popped label as a 
"pipe" model LSP in our description and achieve behaviour 
equivalent to 2(b). I think your behavior specified in 2 (b)
still requires that (i) is true.

The lack of a method for signalling the tunnel mode is, IMHO, an oversight
in the mpls-diff draft. This should be fixed regardless of our TTL draft. In
fact, I would content that our draft is one more reason why it should be
fixed.
>
>I believe there are certain implementations that work this way. 
>

I have no problems with certain implementations working the way you have
outlined above. I am sure there are other implementations that work just a
bit differently. The problem is that the specifications (or lack thereof)
lack sufficient details for multiple vendors to implement a consistent
mechanism for processing TTLs. This is what our draft seeks to address &
clarify and marry that to the tunnel models described in the mpls-diff
draft. I am sure that as our draft matures, we can/will add clauses to
accomodate existing implementation if they do not break the models in
egregious manner - depending of course on the consensus within this group.

Thanks.

-Puneet

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 02 Mar 2001 15:13:28 +0100

Puneet,

>fact, I would content that our draft is one more reason why it should be

The decision to not signal the tunneling mode in the mpls-diff draft is not
an oversight. This very point was actually discussed on the list and a
conscious decision was made to not specify it at that point it time. As you
said in another mail, it is unclear that there is a short term requirement
for service providers to support different tunneling mode on a per LSP
basis. There is however a clear requirement for service providers to be
able to support a different tunneling mode on a per ingress/egress customer
interface (ie customer 1 wants to be treated in Pipe model, customer 2
wants to be treated in Uniform model). Based on this we decided to :
	(1) make sure the spec supports the clear short term requirement (ie
configuration of tunnel mode on a per interface basis)
	(2) not specify mechanisms for a potential-only requirement (ie tunnel
mode signaling)
	(3) make sure the spec is open to adding tunnel mode signaling later if
required

BTW, there are many other options/extensions that have been proposed for
the mpls-diff draft along the way and we tried to use a similar approach
and stick to what was clearly required as opposed to what may be useful
later. 

Now, if you know of service providers that have a clear short term
requirement for supporting tunneling mode on a per LSP basis, then please
let us know and then you could specify signaling in a separate document.

Cheers

Francois
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	[email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________