The MPLS WG Archive

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

In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B9277E@zcard031.ca.nortel.com>, "
David Allan" writes:
> 
> > 
> > But you are misrepresenting me when you say that the
> > differences is not resolvable. In fact the proposal to start 
> > on a fresh document is intended jsut to achieve that. I guess 
> > that if there are two people representing two different ideas 
> > on a subject, the requirement that one of the has to accept 
> > the ideas of the other to be part work seems to be counter-productive.
> 
> I think that cuts both ways. I'm certainly willing to enlarge the document
> to include both points of view. It is a framework document after all.....
> ;-)
> 
> cheers
> Dave


Dave,

A measurement framework that only works for one case, RSVP/TE not
using PHP or ECMP, is of very limited use.  A more useful measurement
framework would work for RSVP/TE but also works for LDP with its mp2p
nature, works with ECMP used with LDP (or RSVP/TE over hierarchical
tunnels).  MPLS OAM defined in the ITU only works for RSVP/TE, no PHP,
no ECMP.  MPLS ping/traceroute works for all of the above cases,
provides more information.  MPLS Ping is also infinitely more
practical because it can be implemented without change to the high
speed forwarding plane (because it involves only altered TTL
processing) or at most minimal change.

As long as you are offering a framework in which MPLS OAM is the
solution and all network architectures for which MPLS OAM doesn't work
are described as "broken" or deficient, there is no sense in the MPLS
WG giving it serious consideration.

If on the other hand the document described an approach that worked
in all conditions that are of interest and also mentioned a tool for a
specific circumstance favored by some, you'd have a document the WG
could consider for advancement.  That is a very different document
from what you now have and it does require starting over.

Curtis