The MPLS WG Archive

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

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