The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

Dave,

Thanks for the comments.  Lets hope Kireeti, Ping, George, et al are
in agreement.

In message <FFFC48AEAA5F7447929F4F0D93FCC12D9C5C0F@zcard031.ca.nortel.com>, "Da
vid Allan" writes:
> 
> 
> Curtis:
> 
> Glad to see the material on TTL (this has been a concern of mine), but a few
> questions/comments...(in line)
> 
> <snipped>
> > +2.2. TTL Processing during Forwarding
> > +
> > +   Three forms of TTL processing for MPLS LSR is specified in
> > +   [draft-ietf-mpls-ttl-04], Uniform, Pipe, and Short Pipe.  The
> > +   Uniform Model corresponds to TTL processing specified in RFC3032.
> > +
> > +   Like IP traceroute, for MPLS traceroute the ingress sends test
> > +   traffic with an initial TTL of one and increases TTL to acquire
> > +   path information.  Unlike IP traceroute, MPLS traceroute may have
> > +   to work with a label stack.
> > +
> > +   The method of TTL processing will not affect tracing the path of
> > +   the top label, if the LSP does not traverse a hierarchical hop as
> > +   defined in [draft-ietf-mpls-lsp-hierarchy-08] or 
> > otherwise enter an
> > +   outer LSP as would occur when LDP takes a directed hop through an
> > +   MPLS RSVP-TE LSP.  For a given hierarchical hop, if the 
> > ingress LSR
> > +   for the inner LSP under test is not the ingress of the outer LSP,
> > +   then testability will be limited if the Pipe Model is used.  
> > +
> > +   For hierarchical LSPs where the outer LSP uses Pipe Mode, if the
> > +   outer (upper) TTL is copied from the inner TTL, 
> 
> <DAVE> The outer LSP seems to use uniform mode as described, not pipe mode
> in order to inherit the TTL of the inner LSP. If the outer LSP was pipe
> mode, then it would start with a fixed value, not copied from the inner LSP.

The draft doesn't actually say that.

Plus, the ingress can think its Uniform Mode and the egress can think
its Pipe Mode.

> > +   then the outer LSP
> > +   will be traced but a number of inner LSP hops (the LSP actually
> > +   under test) will not be traceable.  
> 
> <DAVE> Similarly, the inner LSP PING origin may not be routable LSRs
> transited by the outer LSP. Normally this just results in gaps in any
> traceroute, and if downstream mapping TLV is used, this would most likely be
> identifiable from an analysis of the returned results, but results would
> require interpretation. Of course when uniform model is used and you are
> tracing an inner LSP, and you are routable from the outer LSP, it is not
> clear that the results will be comprehensible - downstream mapping has the
> capability to return the additional level at the ingress, but the error
> codes while tracing that level would appear to be consistently "no mapping
> for the FEC". then when encoutering PHP at that level, the inner label would
> not be known, so presumably the ping request carries implicit null as the
> downstream mapping, and hopefully you synch back up on both "FEC mapping"
> and "is downstream router" past that point. Re-reading this para, re-enfoces
> my opinion that the return code should permit multiple outcomes. If I am
> tracing an inner LSP with uniform model, "no FEC mapping but is downstream
> LSR" is a legit response and knowing both things is useful.

If the core LSRs are not IP reachable except from within the core or
the ingress not reachable from the core, then Pipe Model should be
used or RSVP reply will have to be specified by the ingress.
Otherwise some interpretation of results will be required.  Presumably
the service provider or party initiating the ping can write perl code
or something to accomplish this.  No different from using IP ping.
Some minimal intellegence is needed somewhere.

We provide the tools.  ISP can still try to pound a square peg into a
round hole (or pick your favorite analogy).

> > +   If the outer TTL is
> > +   independently set to a high initial number, then the outer LSP will
> > +   not be traced but instead will appear as a single hop.  The latter
> > +   case is known to be the more common.  If the Uniform 
> > Model is used,
> > +   then all hops of the outer and inner LSP will appear in the trace.
> 
> <DAVE> again with the proviso that the inner ping origin is routable from
> the outer LSR. (BTW, I cannot envision using uniform model across levels
> that are not routable, but then I suspect that not all hardware supports a
> choice, and there is no mechanism to control or configure this).

Same response as above.

IMHO - as someone formerly involved in operation at a very large ISP -
Its almost silly to discuss diagnostics from an outside IP address
that isn't reachable from the inside.

> > +
> > +   When the LSP being tested represents an inner label in the label
> > +   stack and this LSP and an upper LSP both terminate at the 
> > same LSR,
> > +   processing of the S bit on the inner LSP at the egress LSR may
> > +   require change.  For pseudo-wire [ccc, martinni, PW?] and virtual
> > +   private network services [BGPVPN] this label is normally 
> > popped and
> > +   the packet underneath is forwarded uniterpreted to an outgoing
> > +   interface.  
> 
> <DAVE> if the implication here is PHP of service labels at the PE, this is
> what the label stack features seem to be designed to support. You proxy
> testing the PW via testing the PSN with a stack. 

IMHO - PHP was a mistake.  One that we have to live with.

> > +   The presence of another label (absense of the "S" or
> > +   "bottom of stack" bit) should suppress this delivery and instead
> > +   cause inspection of the next label in the stack.  If the egress is
> > +   configured to implement Pipe Mode TTL processing, the TTL of the
> > +   lower label will not expire premempting this forwarding.
> 
> cheers
> Dave

Dave - I hope we're making forward progress.  It seems to me like you
and I are in close agreement at least on the points here.  After I
send the next part (which is related but should go in section 4, not
here) please let me know if I missed something that should be in the
intro part.

Curtis