The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

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

Hi Curtis:

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

ditto....still have a ways to go, mind you

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

Don't quite grok, if the outer is pipe mode, it does not copy from the inner when the outer is pushed.
>
> Plus, the ingress can think its Uniform Mode and the egress can think
> its Pipe Mode.

True, IMHO TTL is a bit of a messy space.

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

Agreed, simply an artifact of overlaying disjoint networks on hardware that uses uniform model. However, as noted above the more interesting case is when it is not a disjoint network, uniform model is used, and I hit a tunnel entrance. Suddently all LSRs along the TE tunnel have no knowledge of the FEC, but the downstream mappings synch up. Like I said, there are multiple outcomes of a single operation and knowing that matters.

If a TE ingress implements uniform model, the downstream mapping TLV should indicate this in the stack returned. If the TE ingress implements pipe model, then the downstream mapping TLV should only return the current level, else I get more errors that require lots of interpretation.

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

Agree it was a mistake, not sure living with it forever is the answer.

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

I think understanding is being achieved, colleagues tell me they are learning a lot following the thread ;-) Time will tell if we turn this into progress...

cheers
Dave

>