Subject: RE: suggested clarification to intro parts of draft-ietf-mpls-lsp -ping-01

From: "David Allan" <[email-masked]>
Date: Wed, 18 Dec 2002 13:38:44 -0500

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.

> +   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 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).

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

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Dec 2002 15:05:26 -0500

Dave,

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

In message <[email-masked]>, "Da
> 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.

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

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

> testing the PW via testing the PSN with a stack. 

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

> > +   lower label will not expire premempting this forwarding.

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

---

From: Bora Akyol <[email-masked]>
Date: Wed, 18 Dec 2002 18:03:38 -0800

>Plus, the ingress can think its Uniform Mode and the egress can think

I think if ingress thinks uniform and egress thinks pipe, the operator has 
a serious misconfiguration issue. In general pipe mode hides its 
intermediary hops from the first layer of the hierarchy.

Bora

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Dec 2002 22:28:52 -0500

In message <[email-masked]>, Bora Akyo
> intermediary hops from the first layer of the hierarchy.

This exercise is *about* finding errors.  Right?

Providers *do* make configuration errors and it is a good thing when
tools help them identify some of the more subtle errors.

Curtis