The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

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