The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Hi Puneet,

I can't follow your reasoning. Let me explain what I am trying to say:

If an egress router is the terminating point of a pipe/uniform tunnel, then the egress router must pop the top label and forward the packet using the label (or IP header) that is beneath the popped label. My question is: What TTL is encoded in the forwarding label (or IP header). The answer is: oTTL, which is equal to oTTL= iTTL-1, in which iTTL determination depends on the tunnel model and is described in section 2.3.

So my suggestion is to add another bullet (say bullet 4) to section 2.4, that says:

4) Pop : This is the terminating point of an LSP tunnel, in which, first the top label is popped and then the packet is forwarded based on the lower label (or exposed IP header). The TTL of the forwarding label (or IP header) is set to:

oTTL = iTTL-1

in which, iTTL is determined based on the type of tunnel (i.e., uniform/pipe) as explained in section 2.3.
 

Yours,
-Shahram

> -----Original Message-----
> From: Puneet Agarwal [mailto:puneet@pluris.com]
> Sent: Tuesday, February 27, 2001 3:09 PM
> To: Shahram Davari; 'Eric Gray'
> Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com';
> 'bsd@cisco.com'; Bora Akyol
> Subject: RE: New TTL Draft
> 
> 
> Hi Shahram,
> 
> Based on the tunnel mode definitions in the -07 version of 
> mpls-diff draft,
> the oTTL determination is not needed explicitly for the "Pop" 
> case. After
> you perform "Pop" (recursively), you need to route (determine 
> the egress
> interface etc) the exposed header (IP packet or label). You 
> never "Pop" the
> label you route on - you can only SWAP, SWAP+Push or PHP 
> (+Push) the label.
> 
> Hence I never added the bullet for "Pop" when determining 
> oTTL as it is not
> a legal operation. If you want, I can add text in section 2.4 
> of the draft
> that a "Pop" is not a legal operation for a label we route 
> on. Would that
> help?
> 
> Hope this clarifies.
> 
> -Puneet
> 
> >-----Original Message-----
> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> >Sent: Tuesday, February 27, 2001 11:19 AM
> >To: 'Puneet Agarwal'; 'Eric Gray'
> >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com';
> >'bsd@cisco.com'; Bora Akyol
> >Subject: RE: New TTL Draft
> >
> >
> >Hi Puneet,
> >
> >Thanks for your reply. Please see my comments in-line:
> >
> >> >2) Section 2.4 does not discuss an important case that is: 
> >> >egress processing of tunnels, i.e. pop and forwarding the 
> >> >packet as MPLS. 
> >> 
> >> Pop (or Egress Pop to distinguish from PHP) is actually 
> >> covered in section
> >> 2.3. The possibly operation when forwarding the packet as 
> >> MPLS are covered
> >> in the 3 bullets  of section 2.4. Combine section 2.3 and 
> >the relevant
> >> section of 2.4 and I think your concern about the missing 
> >> case should be
> >> answered. Hence as far as I can see the case is convered, but 
> >> please let me
> >> know if you still think that it is not addressed.
> >> >
> >
> >As you know there are at least 2 distinct operations that are needed 
> >for TTL processing:
> >
> >1) Determining iTTL
> >2) Determining oTTL
> >
> >Section 2.3 describes the iTTL determination for both PHP and 
> >non-PHP case.
> >Section 2.4 however describes the oTTL determination for PHP 
> >case only. I 
> >can't see anywhere in the draft that talks about oTTL 
> >determination for non-PHP
> >case. Do you see any?
> > 
> >
> >Yours,
> >Shahram 
> >
>