The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

Another way to look at this to treat egress pop as a tunnel termination.

Bora


On Tue, 27 Feb 2001, Puneet Agarwal wrote:

> Eric,
> 
> From the perspective of the LSR in question, the case you described
> would be equivalent to a PHP (as you suspected) and not an "Egress Pop".
> The ttl processing for the PHP case would apply.
> 
> My conceptual model of "Egress Pop" has been that it is performed by the
> egress LSR to exit the encapsulating tunnel and the exposed packet is
> then routed. If you route on a label and then pop, then you are
> essentially performing a PHP (from the perspective of the data path) and
> not an Egress Pop.
> 
> Hope this helps.
> 
> -Puneet 
> 
> >-----Original Message-----
> >From: Eric Gray [mailto:eric.gray@sandburst.com]
> >Sent: Tuesday, February 27, 2001 12:33 PM
> >To: Puneet Agarwal
> >Cc: 'Shahram Davari'; 'mpls@uu.net'; 'flefauch@cisco.com';
> >'liwwu@cisco.com'; 'bsd@cisco.com'; Bora Akyol
> >Subject: Re: New TTL Draft
> >
> >
> >Puneet,
> >
> >    I am somewhat confused by this reply - especially in the
> >context provided by the enclosed discussion.
> >
> >    It is certainly possible to perform an egress pop of a
> >label.  I believed that to be what you were saying earlier.
> >Yet this is exactly the same thing as what you are saying
> >you would never do below.
> >
> >    For example, if I am providing a port-based VPN service
> >using MPLS, it is very likely that I will use MPLS labels to
> >get packets to the egress port. Now suppose (as is likely
> >to be true at least sometimes) that the next router beyond
> >the service provider router is not an LSR (even of the
> >stripped down version that can only give implicit NULL
> >labels).  Then the packets that the egress LSR forwards
> >to this next hop must be IP packets - so the label used to
> >get the packets to the egress port of the egress LSR must
> >be popped after they are used to route the packets to the
> >egress port.
> >
> >    From the forwarding engine's point of view, this is exactly
> >the same behavior as you would get using PHP.  The question
> >seems to be, would the behavior with respect to TTL defined
> >for PHP also apply in this case?
> >
> >--
> >Eric Gray
> >
> >You wrote:
> >
> >> 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
> >> >
> >
>