The MPLS WG Archive

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

Shahram,

    I see no reason why Puneet's draft should affect TTL processing
in intermediate LSRs.  I believe this is well defined elsewhere.

    By the way, an LSR that pops a label is not an intermediate LSR
with respect to the LSP for which that label applied.

--
Eric Gray

You wrote:

> Hi Puneet,
>
> > Hi Shahram,
> >
> > As I had briefly mentioned in reply to Eric's earlier email on the Pop
> > issue, we do not perform a "Route and a Pop" - that is
> > actually treated as a
> > "Route and a PHP".
> >
>
> I am not talking about "route and pop" rather I am talking about "pop and route".
>
> > To quote from our ttl draft section 2.4:
> >
> > "For packets that are routed as MPLS, we have three cases"
> >
> > the semantics of "routed as MPLS" implies that any egress
> > Pops have already
> > been performed. If you think that this was unclear in the
> > draft then I will
> > clarify it.
> >
>
> Oh yes. Finally I found the reason for confusion. It is absolutely unclear from "routed as MPLS" that a pop is done before hand. The reason is that the title of the draft says "TTL processing in MPLS networks", while section 2.4 assumes that the title is "TTL processing in MPLS tunnel end-points".
>
> Do you intend to cover TTL operation for the intermediate LSRs. If so you have two choices:
>
> 1) Clarify that section 2.4 applies to a tunnel ultimate/penultimate node, and then add another section for the TTL processing in the intermediate LSRs.
>
> 2) Clarify bullets 1,2,3 in section 2.4 by adding a pop to them such as pop+Swap, pop+swap+push, pop+PHP, and then add one more bullet for swap-only.
>
> > >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.
> >
> > I would be happy to include the text with a few modifications:
> >
> > 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).
> > Note that this operation can occur recursively. The iTTL is
> > updated as explained in section 2.3. The outgoing TTL would
> > be determined by the last non "Pop" operation performed
> > on the packet.
> >
> > Would such a text address your concerns?
> >
>
> There is no need for this text. Please see above.
>
> Yours,
> -Shahram
>
>
>