The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

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

Curtis

------- Forwarded Message

Return-Path: curtis@workhorse.fictitious.org
Delivery-Date: Tue Dec 10 10:57:46 2002
Return-Path: <curtis@workhorse.fictitious.org>
Received: from localhost (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA40659
	for <curtis@localhost>; Tue, 10 Dec 2002 10:57:46 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Received: from gateway2.fictitious.org [209.150.1.252]
	by localhost with POP3 (fetchmail-5.5.1)
	for curtis@localhost (single-drop); Tue, 10 Dec 2002 10:57:46 -0500 (EST)
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230])
	by gateway2.fictitious.org (8.11.6/8.11.6) with ESMTP id gBAFvj860956
	for <curtis@fictitious.org>; Tue, 10 Dec 2002 10:57:45 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA40637;
	Tue, 10 Dec 2002 10:52:05 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200212101552.KAA40637@workhorse.fictitious.org>
To: neil.2.harrison@bt.com
cc: curtis@fictitious.org, Shahram_Davari@pmc-sierra.com,
        dallan@nortelnetworks.com, swallow@cisco.com, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: Last call on LSP Ping 
In-reply-to: Your message of "Tue, 10 Dec 2002 13:43:24 GMT."
             <0536FC9B908BEC4597EE721BE6A35389014CFCE9@i2km07-ukbr.domain1.systemhost.net> 
Date: Tue, 10 Dec 2002 10:52:04 -0500
From: Curtis Villamizar <curtis@fictitious.org>
X-UIDL: p/a!!(*J!!U)O!!)(>!!


In message <0536FC9B908BEC4597EE721BE6A35389014CFCE9@i2km07-ukbr.domain1.system
host.net>, neil.2.harrison@bt.com 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