The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Feb> msg00355



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

New TTL Draft

  • From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
  • Date: Tue, 27 Feb 2001 13:16:13 -0800
  • Cc: "'mpls@uu.net'" <mpls@UU.NET>, "'flefauch@cisco.com'" <flefauch@cisco.com>, "'liwwu@cisco.com'" <liwwu@cisco.com>, "'bsd@cisco.com'" <bsd@cisco.com>, Bora Akyol <akyol@pluris.com>

Hi All,

Interestingly a similar draft was posted today:

http://www.ietf.org/internet-drafts/draft-satoru-mpls-1hop-lsp-00.txt

Yours,
-Shahram

> -----Original Message-----
> From: Shahram Davari 
> Sent: Tuesday, February 27, 2001 3:59 PM
> 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,
> 
> 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 
> > >
> > 
> 


  • Follow-Ups:
    • New TTL Draft
      • From: "S.Matsushima" <satoru@japan-telecom.co.jp>