Subject: RE: draft-ietf-mpls-lsp-ping-01.txt - ECMP considerations

From: "David Allan" <[email-masked]>
Date: Tue, 10 Dec 2002 20:51:58 -0500

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.

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.

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. 

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Dec 2002 18:26:05 -0500

In message <[email-masked]>, "
> 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.

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

> true for any approach that is not ICMP monotonically going through the IP

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.

> of failure once somthing goes wrong.  

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