Subject: RE: Last call on LSP Ping

From: [email-masked]
Date: Tue, 10 Dec 2002 13:43:24 -0000

Thanks Curtis,  please see below.  regards, Neil

<snipped to specific points>
Curtis Villamizar wrote 10 December 2002 03:33
> > NH=> I refer to the RSVP bit.  If a pkt gets misdirected 
> and is requesting a
> > return by the RSVP control-plane, then of course as you 
> rightly observe
> > there has to be such a return control-plane path available. 
>  But how is it
> > possible that a pkt which is misdirected to some arbitrary 
> egress point will
> > have a RSVP return path back to some fixed source point?  
> This appears not
> > to be a sensible thing to assume.  So this option (ie using 
> RSVP) does not
> > appear to cater for the needs of identifying where 
> misdirected traffic ends
> > up.
> 
> I looked at this again and it appears I had this wrong. 
NH=> Yes, I agree it's not immediately obvious.  And if you are having
problems understanding all this think about how others must be finding it.  

> If the
> "Downstream Mapping" was used to form a RESV, then this would be fine,
> but it is not the case.
> 
> In order to have *any* MPLS/TE LSP going to an adjacent router, there
> must be an RSVP adjacency.  The route up to the point where the path
> went wrong is in the MPLS-ping packet payload if the "Downstream
> Mapping" is present so the router could in principle send the packet
> back hop by hop in RSVP.  I was assuming that the "Downstream Mapping"
> could be inverted but I see that the intent is to simply add the
> LSP_ECHO in the normal RESV for the LSP.  As is it is just a
> continuity test.
NH=> Agreed....that was precisely my point, ie this can only be used to
detect breaks.  My understanding of the intention of this mode was to
resolve the break to either 'go' or 'return' directions (on the assumption
that using an RSVP return path for comms is reliable since it indicates
itself whether up/down).
> 
> It seems that error indication on misdirected traffic is only possible
> if IP routing is used to deliver the reply.
NH=> Agreed, this was what I was driving at in my 2nd set of questions that
I posed 5 Dec, and specifically Q6 therein.  I am still waiting a response
on all my postings.....to repeat that specific question:
"6	In the same section......why is there an option to reply by the RSVP
control-plane?  What scenario is this addressing that the above (NH=> ie
using IP only) doesn't?  Further, some guidance on when to select which
option would be useful."
> 
> Even so, if the packet is misdirected, at some hop the packet arrives
> at the wrong router.  In traceroute mode you can determine when this
> occurs and which router the traffic is being misdirected towards (if
> IP can be used to return the packet).
NH=> Yes.  But you don't want to be running trace route continually IMO.
Trace route should be available to run *after* a mismerging defect is
detected as an ad hoc diagnostics tool.  RSVP return option fails here as we
have noted....hence I ask why bother with it?  However, I am still unclear
what happens wrt to setting the router alert option (to attempt to avoid LSP
return paths?), esp in the case where the network is just LSPs and no IP
(return) fowarding is possible (see Note).  I also asked about this in my
earlier 2nd posting in Q5....still no response, so here it is again:
"5	In the same section.....can you please explain in a little more
detail why there are 2 IPv4/UDP (and no v6??) reply modes, one without
router alert set and one with router alert set?  The text seems to indicate
the latter is more reliable than the former."

Note - IMO it's not architecturally correct to be asking a client (or
server) layer network technology (any) or a signalling protocol (any, and
should include the case of *none*, ie static provisioned) to be taking a
critical role in the data-plane fault management of a layer network....here
MPLS, though this principle is general to any layer network.  However, I
can't easily/simply see how we are going to crack the problems of merging in
a co forwarding mode (ie mp2p) without breaking the architecture in some
way.  But let's try and keep the 'nifty hacks' to the minimum please and try
and respect the layered architecture as far as possible. Let's also try and
keep it simple.  It would have helped if we had had some agreed requirements
up front that we were shooting at.  This was done for the p2p case in Y.1710
and then with the solutions in Y.1711....not only do these respect layered
architectures but they are both very powerful and very simple.  But they
won't jive with the fault-management complexities mp2p throws up though, so
we must keep working on this. 
<snipped>

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 10 Dec 2002 10:52:04 -0500

In message <[email-masked]
> problems understanding all this think about how others must be finding it.  

It was clearly written.  I didn't bother to read this part carefully
enough.  Lets put the blame where it belongs.

> using IP only) doesn't?  Further, some guidance on when to select which

I wouldn't mind getting rid of this.  C&W (for example) has talked
about running a no-IP routing core with MPLS over it.  I think this is
a very bad idea.  It is speculative on my part but I think someone is
either directly driving this or it was added to head off any
objections that might arise.  I thought you were one that insisted on
a means to decouple diagnostics from an IP control plane.  Maybe I'm
mistaken.

> the latter is more reliable than the former."

If the continuity test fails, it would make sense to run traceroute.
If a fault has occurred that is not due to an error that is evident in
the control plane, then this would point to where the error is.

> we must keep working on this. 

Implementation is greatly simplified by putting most of the fault
management smarts at the application layer.

Lets just agree to disagree about what is a nifty hack.  I'll be
sending a mesage on ECMP shortly.  Please feel free to comment then.

Curtis