Subject: RE: New TTL Draft

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Feb 2001 13:16:13 -0800

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: [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; 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:[email-masked]]
> > Sent: Tuesday, February 27, 2001 3:09 PM
> > To: Shahram Davari; 'Eric Gray'
> > Cc: [email-masked]'; [email-masked]'; [email-masked]';
> > [email-masked]'; 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:[email-masked]]
> > >Sent: Tuesday, February 27, 2001 11:19 AM
> > >To: 'Puneet Agarwal'; 'Eric Gray'
> > >Cc: [email-masked]'; [email-masked]'; [email-masked]';
> > >[email-masked]'; 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 
> > >
> > 
>

---

From: "S.Matsushima" <[email-masked]>
Date: Wed, 28 Feb 2001 21:55:52 +0900

Shahram,

This is Satoru Matsushima.

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

Thanks,:-)
Actually, this draft consist of three elements:

  - TTL Processing expansion.
  - Label distribution method for 1-hop LSP.
  - The possible to "LSP KeepAlive" using 1-hop LSP.

So, this draft was not only TTL processing, and it was stated about
for using 1-hop LSP. Because, I had to describe these elements when I
tried to write about realizing 1-hop LSP in this draft.

I think Puneet's draft(and after discussion in ML) described very well
TTL procesing for hierarchical LSP, but the 1-hop LSP(Pipe model LSP)
is not a thing only for Diff-Serv. It is very usefull for MPLS/VPN
operators. (I'm a MPLS/VPN operator.;-)
Therefore, I think TTL processing expansion should be described more
generally and be careful in label distribution mode; DU or DoD.
(we call "Cloud model" and "Per LSP model")

"LSP KeepAlive" ability is extremely important for the applications
which use LSP but cannnot know the state of LSP itself(for instance,
BGP/MPLS VPNs).
I described a method of "LSP KeepAlive" using 1-hop LSP in this draft.
How do you think about this?

regards,

--
Satoru Matsushima

From: Shahram Davari <[email-masked]>
Subject: RE: New TTL Draft
Date: Tue, 27 Feb 2001 13:16:13 -0800