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

From: "David Allan" <[email-masked]>
Date: Wed, 18 Dec 2002 15:33:23 -0500

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

---

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

In message <[email-masked]>, "Da
vid Allan" writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_001_01C2A6D4.B61AE56E
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> Hi Curtis:
> 
> > Dave,
> > 

I agree.

> when the outer is pushed.

My fault for not being clear on that.

I meant the TTL draft, draft-ietf-mpls-ttl-04, doesn't say that you
MUST put 255 in the outer TTL and in fact you are allowed to put the
TTL from the lower label into the outer label.

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

This would be a minor error but I thought it was worth mentioning what
MPLS traceroute would do with this situation.

<big snip>
> outcomes of a single operation and knowing that matters.

That's in a comment in the second part gorp I just sent.  I didn't
solve it, just pointed it out.

> else I get more errors that require lots of interpretation.

There really needs to be a mapping TLV that says "I'm sticking your
bits into an LSP and setting TTL such that you'll see the hops" and
sends the FEC of the LSP that will be visible.

<small snip>
> Agree it was a mistake, not sure living with it forever is the answer.

We're stuck with it.  Old core routers never die.  They just get moved
to the edge (somewhere).

> learning a lot following the thread ;-) Time will tell if we turn this into

Kireeti is out there.  He just has real work to do.

Regards,

Curtis

---

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

>TTL from the lower label into the outer label.

This in fact is correct.

Bora