Subject: RE: on the mpls oam framework

From: "David Allan" <[email-masked]>
Date: Tue, 11 Nov 2003 09:09:35 -0500

Loa:

> note that Neil, Dave and I agree on that the disconnect is
> there, I'm not certain that they agree with how I described 
> (but that is also part of the disconnect :) ).

Again IMHO if there is a disconnect, it is what MPLS has become vs. its
origins as exclusively an IP helper. There is already a reasonable body of
evoluiton that is not covered in 3031. FOr example 3270 cast diffserv as
somthing entirely different from the concept of FEC, yet when reading 3031
you would expect diffserv to come under the umbrella of FEC. Further TTL
handling (pipe and uniform models) is not addressed either. Perhaps it is
time to respin 3031. Especially if folks want to exclusively clamp it down
to IP, 2547 and PWs.  
 
> Anyway - I guess that the core of the matter is that the
> architecture is written positioning mpls as a part of the ip 
> protocol suite, while the oam framework rather position it as 
> a "newer and better ATM" that necessarily needs to have all 
> the features of ATM.

I thought it was supposed to be an IP helper. If it is rigorously
constrained to being no more than IP, it adds no value, IP is sufficient and
complete. However MPLS does introduce new modes of failure into IP networks,
and does have this label swapping dataplane for which the black box behavior
of the network is a function of the control plane used. We are now carrying
other than IP, and the label stack depth (depending on the proposals you
see) can have several control planes both stacked and/or side by side, the
overall implications being rather subtle. That some OAM standards are
focused on p2p CO behavior (such as Y.1711) I would think is still
consistent with the data plane specified in 3031. That others (Y.17fec-cv,
LSP-PING) focus on broader behaviors when other control planes are used (LDP
etc.) is also consistent. 

> 
> This shows up in a numbe of places, the concept of layers and
> levels is, not what I see as useful in the type of IP network 
> I've been involved in.

That there are VPN layers, PW layers, transport layers, inter area solutions
that all have potentially unique control planes, and relationships between
the layers. The absence of a UNI means that network elements participate in
multiple control planes, and potentially multiple networks.
 
> The definition of "LSP" is not what is in the architecture document.
> 
> PHP is designed out by the oam framework, but an in by the
> mpls architecture.

Not designed out, but needs to be worked around for some styles of
measurement. It is a MAY in 3031 which suggests that the original authors
didn't think it universally suitable. I can also "mine" the list for lots of
"that was a mistake" testimonials....

> 
> 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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Nov 2003 11:32:25 -0500

In message <[email-masked]>, "
> to include both points of view. It is a framework document after all.....

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