The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Nov> msg00153



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

on documenting ECMP (was on the mpls oam framework)

  • From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
  • Date: Tue, 18 Nov 2003 13:21:46 -0500
  • Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET

Dave, et.al.

In one of the side-branches of this discussion, the name Dijkstra came up a couple of times. Apart from inventing the famous algorithm, Dijkstra did important 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 program 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 let's give it a try.

I think that ECMP is an issue only for a subset of traffic. ECMP is not an issue 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. 

The question in my mind is: for the traffic that is subject to ECMP, is it really 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 around it?

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 applications, end-to-end OAM would not be relevant, but local loopback tests might be much more useful.


Peter 


> -----Original Message-----
> From: David Allan [mailto:dallan@nortelnetworks.com]
> Sent: Tuesday, November 18, 2003 12:00 PM
> To: 'curtis@fictitious.org'
> Cc: 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: RE: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> Curtis:
> 
> You misuderstand me, I lump all tools (including LSP-PING, 
> BFD, VCCV, ITU
> efforts) together under the blanket of OAM.
> 
> enough for now
> Dave
> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> > Sent: Tuesday, November 18, 2003 11:56 AM
> > To: Allan, David [CAR:NS00:EXCH]
> > Cc: 'curtis@fictitious.org'; 'tnadeau@cisco.com'; mpls@UU.NET
> > Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> > 
> > 
> > 
> > In message 
> > <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280B@zcard031.ca.nortel.c
> > om>, " David Allan" writes:
> > > Curtis:
> > > 
> > > >From my perspective there is simply OAM.
> > 
> > Then withdraw as an author of the framework document.  That 
> > would be like Ohta writing the IP over ATM framework 
> > (Conventional IP or ATM advocate).
> > 
> > > To date a fundamental obstacle to progressing OAM has been 
> > the issue 
> > > of how OAM flows are distinguished, esp in the presence of 
> > ECMP. When 
> > > a packet needs to be IP, when it needs to not alias as IP, 
> > > restrictions on the use of reserved labels to distinguish 
> flows and 
> > > where such labels can appear in the stack, yadda yadda 
> > yadda. This has 
> > > been an obstacle to discussing the actual functionality 
> required or 
> > > any other relative merits as all solutions have been held 
> > up to this 
> > > problem first without the actual problem to be solved being 
> > documented 
> > > anywhere.
> > > 
> > > Taking ECMP off the table as an issue by documenting at a 
> > minimum the 
> > > protocol aspects so we can get on with the actual functionality 
> > > required would IMO be progress. The lack of information has 
> > been THE 
> > > obstruction all along.....
> > > 
> > > cheers
> > > Dave
> > 
> > See my prior email.  If OAM doesn't work with ECMP as it 
> > exists in the real world then it is just an applicability 
> > issue that needs to be documented.
> > 
> > Curtis
> > 
>