The MPLS WG Archive

["S.Matsushima" <satoru@japan-telecom.co.jp>]

Shahram,

This is Satoru Matsushima.

> Hi All,
> 
> Interestingly a similar draft was posted today:
> 
> 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 <Shahram_Davari@pmc-sierra.com>
Subject: RE: New TTL Draft
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: '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 
> > > >
> > > 
> > 
> 
>