The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Curtis:

>From my perspective there is simply OAM.

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



> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> Sent: Tuesday, November 18, 2003 10:39 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'curtis@fictitious.org'; 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: Re: on the mpls oam framework 
> 
> 
> 
> In message 
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EC@zcard031.ca.nortel.c
> om>, " David Allan" writes:
> > Curtis:
> > 
> > > MPLS Ping has a means defined to determine that an ECMP
> > > branch point exists, and a means to provide the means to 
> > > exercise each branch. This is all independent of the 
> > > algorithm used to accomplished the split, hash based or 
> > > other.  That is a move forward technically.  The alternate of 
> > > randomly spraying addresses across the 127/8 space has also 
> > > been suggested as a solution that from a practical standpoint 
> > > covers the problem, though with no certainty.
> > > 
> > > This is a solved problem.
> > 
> > Your characterization of the solution is somewhat like the dancing 
> > bear in the Moscow circus. The wonder is that it dances at all.....
> > 
> > The binary characterization of "a solution", "no solution" IMHO is 
> > insufficient and as I've noted in the comment to Rahul on 
> VCCV, there 
> > are other implications beyond simply the ability to test IP path 
> > permutations.
> > 
> > cheers
> > Dave
> 
> 
> You chopped off my next sentence.  My next two sentences were 
> "Can we stop moving backwards.  If you can improve on the 
> solution, that would be welcome too."  But you prefer to 
> remove that statement.
> 
> This is the path the IETF is currently taking and if you want 
> to contribute to it, please help it move forward.  If you 
> don't want any part of it, don't be an obstructionist.  There 
> was and is no obstruction to your work in the ITU, just no 
> acceptance of it.
> 
> There are many cases in which more than one solution is 
> pursued, OSPF and ISIS, RSVP/TE and CR-LDP, etc (anyone 
> remember Classic IP-over-ATM and Conventional IP-over-ATM).  
> The rule of politeness when this occurs is you don't ostruct 
> the other work and see which one gets deployed.  If both 
> solutions have merit with some tradeoffs favoring one or the 
> other in different circumstances or uses, both will continue to exist.
> 
> Curtis
>