The MPLS WG Archive

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



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

on the mpls oam framework

  • From: Curtis Villamizar <curtis@workhorse.fictitious.org>
  • Date: Tue, 18 Nov 2003 10:38:38 -0500
  • cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EC@zcard031.ca.nortel.com>, "
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