The MPLS WG Archive

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

If you want to trivialize the framework draft to the ITU stuff only, read
the Y.17fec-cv overview draft. 

IMHO You are persisting in ignoring what you don't want to see.

rgds
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> Sent: Tuesday, November 11, 2003 11:32 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'loa@pi.se'; Shahram Davari; MPLS wg; George Swallow; Alex Zinin
> Subject: Re: on the mpls oam framework 
> 
> 
> 
> In message 
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B9277E@zcard031.ca.nortel.c
> om>, " 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
>