The MPLS WG Archive

["Busschbach, Peter B (Peter)" <busschbach@lucent.com>]

Curtis,

Something must have been lost in the translation, because you seem to interpret most of my statements opposite to what I intended. I like ECMP. My email was intended as a request to accept ECMP as a given and accept that it leads to non-deterministic behavior in the network.

For fear of further slipping away from the compromise that you referred to, I will leave most of your misinterpretations unanswered, but I do have a question about one of your statements. Please see in-line.

Peter

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Tuesday, November 18, 2003 2:03 PM
> To: Busschbach, Peter B (Peter)
> Cc: 'David Allan'; 'curtis@fictitious.org'; 'tnadeau@cisco.com';
> mpls@UU.NET
> Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> 
> 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.

I don't understand why RSVP-TE and ECMP are orthogonal. If one uses RSVP-TE to reserve bandwidth between two points, doesn't that nail down an exact end-to-end path? 


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