The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

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