The MPLS WG Archive

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

Curtis:

I'm FAR from throwing my hands up in the air..... ;-) Just trying to move
the mountain (and some thinking). 

If I did not make it clear, for figuring out what went wrong once yoou know
somthing is wrong, I bellieve you are on the right path, and I've privately
forewarded some suggestions as to how the approach can be improved for the
cascaded case. I'd much rather know how to authoriatively test somthing than
simply guess.

As for knowing somthing is broken in a reasonable time, I still think the
aggregate of probe behavior needs to be observed, and I'll bring forward
some stuff for SF.

Cheers
Dave



> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Wednesday, December 11, 2002 6:26 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: curtis@fictitious.org; mpls@UU.NET
> Subject: Re: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations 
> 
> 
> 
> In message 
> <9FBD322B7824D511B36900508BF93C9C06746B4D@zcard031.ca.nortel.com>, "
> David Allan" writes:
> > Hi Curtis:
> > 
> > I think what you are proposing illustrates the complexity 
> of the problem,
> > and highlights that we need a different approach in order 
> for detecting
> > problems to be tractable. IMHO such constructs cannot be 
> reliably and
> > proactively tested from a single arbitrary upstream point 
> and what you
> > describe illustrates the complexity of actually performing 
> meaningful
> > testing. This is compounded exponentially as load spreading 
> points are
> > cascaded between the ingress and any point of failure.
> 
> Suggesting that we throw our hands in the air and give up is not
> constructive.  Fortunately you bring up some useful points below as
> "food for thought" that does move us forward.  Thanks.
> 
> > IMHO the correct answer is to proactively test from more 
> than one point in
> > the network and depend on the aggregate effect of the 
> whole, and not try to
> > produce a protocol that reverse engineers proprietary boxes.
> 
> There is nothing any more proprietary than slightly differing
> implementations of OSPF ECMP would be.
> 
> The world out their has a deployed based.  All of the MPLS
> implementations that I know of allow ECMP to be configured enabled or
> disabled and ISPs don't have to turn it on but do.  One of our
> customers made it very clear to us that they required that we
> implement ECMP for LDP.  Most indicate MP for TE (split IP traffic at
> ingress) and LDP are requirements.
> 
> > Each load spreading point should behave as a set of 
> ingresses (from the POV
> > of probe injection) for some low frequency of probes. You 
> live with not
> > necessaraily exercising all aspects of the actual load 
> spreader but that is
> > true for any approach that is not ICMP monotonically going 
> through the IP
> > address plan. 
> 
> If there are 24 paths from A to B, and the traceroute step if
> successfull, will return sufficient information to provide 24
> destinations that will exercise all of the paths.
> 
> > This will provide bounded error detection in the network. 
> Ideally you need
> > some smarts to locate the probe source closest to and 
> upstream of the point
> > of failure once somthing goes wrong.  
> > 
> > food for thought
> > Dave
> 
> I don't think injecting traffic at each branch point will prove
> necessary even for multiple branch points.  If in a deployment it was
> determined that it was needed, no change to the MPLS-ping protocol is
> needed except to note that the traffic can be injected at a midpoint
> LSR, not just at an ingress LSR.  This may already be intended by the
> authors but not specifically indicated.  In such a usage, the ingress
> would test up to and through the first branch point, including all
> paths leading out of the first branch point.  At the first branch
> point, each branch would be tested up to and through each second
> branch point.  This would continue until all branches reached the
> egress.  This would still require use of more than one address from
> 127/8 and would require that the source of the MPLS-ping requests be
> notified of the means to exercise the one branch point immediately
> downstream.
> 
> If we wanted to retain the ability to test from the ingress, then we'd
> have to include MPLS-ping protocol support to allow a branch point to
> proxy test the MP LSP further downstream and report back to the
> ingress.  This would not be overly difficult.  It also removes any
> concern about correlating the hash behaviour of multiple branch points
> to exercise paths further downstream and in doing so completely
> removes the need to know anything about the algorithm used for MP,
> other than one or more address to exercise each immediate branch.
> 
> Curtis
>