The MPLS WG Archive

[Puneet Agarwal <puneet@pluris.com>]

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
>> >
>