The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.lucent.c
om>, "Busschbach, Peter B (Peter)" writes:
> Dave, et.al.
> 
> In one of the side-branches of this discussion, the name Dijkstra came up a c
> ouple of times. Apart from inventing the famous algorithm, Dijkstra did impor
> tant work in the area of correctness proofs and concurrent processes. One of 
> his insights was that non-determinism is a powerful concept and that a progra
> m should be written in such a way that its correctness can be proven, even in
>  the face of non-determinism.
> 
> We have to be careful translating this to OAM (after all, you don't want your
>  service provider to blame non-determinism when your connections fail), but l
> et's give it a try.

Nice thought followed by a cheap shot, but fine.  I understand that
you don't like ECMP and no one is asking you to like it, simply to
accept that it is part of the architecture and it will be covered by
whatever OAM emerges from the IETF.

> I think that ECMP is an issue only for a subset of traffic. ECMP is not an is
> sue for PW-traffic, since VCCV provides a solution. ECMP is not an issue for 
> services with QoS guarantees, where RSVP-TE is used to set up the connection,
>  because an explicit path is nailed down. 

QoS and explicit path are orthogonal.  Some provider may feel that
they must combine the two in their service but it is not generally the
case.  QoS and ECMP are also orthogonal.  Lets not try to sneak in
assertions that may be true in your case but are not generally true.

> The question in my mind is: for the traffic that is subject to ECMP, is it re
> ally crucial to know exactly how traffic is routed? Shouldn't we just embrace
>  non-determinism for the advantages that it provides and find ways to work ar
> ound it?

We did that in MPLS Ping.  The ingress can determine from the midpoint
(essentially by the midpoint telling it) where ECMP branches exists
and how to exercise each branch.  This method is deterministic and
will exercise all paths.  The alternate is to randomly spray across
the 127/8 space, which is non-deterministic but arguably will also
exercise all paths.  The latter method can detect loss but not measure
the loss experienced on any given path (loss may be concentrated in a
subset of the traffic).

If other techniques want to do something similar to determine how to
exercise ECMP paths, then they become applicable where ECMP is used.
If they don't they are simply not applicable when ECMP is used.  One
provider may choose to disable ECMP and use a technique that works
only with ECMP disabled.  Another provider may choose to keep ECMP
enabled and use a different OAM technique that works with ECMP.

> For example, when I surf the web, I don't need an ISP to be able to send OAM 
> packets along the exact same path that I used five minutes ago. For such appl
> ications, end-to-end OAM would not be relevant, but local loopback tests migh
> t be much more useful.

I'm quite confident that the PC in my home has not sent any OAM
packets to the IETF mail servers to verify the path to the mail
server.  But quite honestly this has nothing to do with the discussion
of the OAM framework.  If I want to test to see if my ISP is live or
the path to the IETF mail server is OK, I just use IP ping and
traceroute.  Loopback tests are accomplished for your example.

> Peter 

We had some compromise and I fear that we are now slipping back to
arguing about whether ECMP is part of the architecture.  I hope that
is not the case.

Curtis