Subject: RE: on the mpls oam framework

From: Shahram Davari <[email-masked]>
Date: Tue, 11 Nov 2003 08:52:12 -0800

Curtis,

I think you are misreading the draft. It doesn't say that there shouldn't be any OAM
tools for ECMP, PHP, Mp2p. All it says is that special considerations and complexities
are involved in those cases, and it outlines the issues that needs to be considered
while designing an OAM tool.

So I don't see your point as a valid point to discard this draft, and I am sure many
other WG members agree with me.

Yours,
-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:[email-masked]]
>Sent: Tuesday, November 11, 2003 11:32 AM
>To: David Allan
>Cc: [email-masked]'; Shahram Davari; MPLS wg; George Swallow; Alex Zinin
>Subject: Re: on the mpls oam framework 
>
>
>
>In message 
><[email-masked]>, "
>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
>

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Nov 2003 13:07:28 -0500

In message <[email-masked]
sierra.bc.ca>, Shahram Davari writes:
>  
> Curtis,
>  
> I think you are misreading the draft. It doesn't say that there
> shouldn't be any OAM tools for ECMP, PHP, Mp2p. All it says is that
> special considerations and complexities are involved in those cases,
> and it outlines the issues that needs to be considered while designing
> an OAM tool.
>  
> So I don't see your point as a valid point to discard this draft, and
> I am sure many other WG members agree with me.
>  
> Yours,
> -Shahram

I think the draft as is could be submitted as an informational draft
submitted by Dave outside the work group.

As a framework for OAM it is a diversion from progress rather than a
step toward progress.  It would be enough to give a simple statement
that any form of OAM which simply injects traffic at ingress and
counts traffic at egress is insufficient in many circumstances and
perhaps briefly enumerate the circumstances rather than describe them
in detail.  The framework can then outline requirements agreed to in
the WG and if it follows other framework documents it may touch on
solution approaches concentrating on those that work within the entire
framework (work in all cases, meet the largest set of requirements).
Mention can be made of those approaches that work in a limited context
but the overall emphasis should not be on evaluation of the
implications of network topology on a specific solution that has been
rejected by the WG.

Curtis

---

From: Eric Rosen <[email-masked]>
Date: Thu, 13 Nov 2003 10:14:37 -0500

Curtis> I think the draft as is could be submitted as an informational draft
Curtis> submitted by Dave outside the work group.

Curtis> As a framework for OAM it is a diversion from progress rather than a
Curtis> step toward progress.

Very well put!  I agree completely.