Subject: oops (was Re: Last call on LSP Ping)

From: Curtis Villamizar <[email-masked]>
Date: Tue, 10 Dec 2002 12:30:49 -0500

Thought this was part of a separate private thread.  Sorry.

Curtis

------- Forwarded Message

Delivery-Date: Tue Dec 10 10:57:46 2002
To: [email-masked]
cc: [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Last call on LSP Ping 
Date: Tue, 10 Dec 2002 10:52:04 -0500
From: Curtis Villamizar <[email-masked]>

In message <[email-masked]
host.net>, [email-masked] writes:
> > 
> > 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.  

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

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

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.

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

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.

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

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

------- End of Forwarded Message