The MPLS WG Archive

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

In message <EB6D4918A175D311971E00204840E2820ABD3B8E@whq-msgusr-01.pit.comms.ma
rconi.com>, "Rutemiller, John" writes:
> Curtis,
> 
> > Network stability is more important goal than measurement accuracy.
> > Scalability is an important goal (see RFC1958 Architectural Principles
> > of the Internet).  Here's a sample:
> > 
> >    3.3 All designs must scale readily to very many nodes per 
> > site and to
> >    many millions of sites.
> > 
> >    3.4 Performance and cost must be considered as well as 
> > functionality.
> > 
> >    3.5 Keep it simple. When in doubt during design, choose 
> > the simplest
> >    solution.
> > 
> >    3.6 Modularity is good. If you can keep things separate, do so.
> > 
> >    3.7 In many cases it is better to adopt an almost complete solution
> >    now, rather than to wait until a perfect solution can be found.
> 
> 
> So based on items 3.5 and 3.6, you advocate an MPLS-OAM solution. :)
> 
> 3.5 Keep it simple
> - MPLS-OAM uses a single one-way message to check the health of the LSP.
> - ICMP/LSP-PING requries two two-way messages.
> 
> One vote for MPLS-OAM.


Clearly I don't support this.  It is on the principle of "as simple as
possible but no simpler".

Two types of feedback is needed to the sender/ingress.  The ingress
does LSP setup and handles any required end-to-end restoration so it
needs to know when the LSP is down.  The sender needs to know if the
send rate is too high.  Without that a one way is too simple to be
adequate.


> 3.6 Modularity is good.
> - MPLS-OAM is confined to the data plane under test.
> - ICMP/LSP-PING involves the data plane under test(LSP), a data plane
>   not under test (IP) and a control plane.
> 
> One more vote for MPLS-OAM.


You're pretty desparate for an argument in favor of MPLS.


> MPLS-OAM can meet 3.3 and 3.4. ICMP was implemented in hardware. You
> can do the same with MPLS-OAM.

The reciever end (the part that does the processing of returned ICMP
echo replies, not the simple echo reply generation in response to an
echo request) will be done by a microprocessor.  The MPLS-OAM
processing on packet reception (if ever implemented) will be done by a
microprocessor.  The only thing that is very fast is sifting through
packets (for example, filtering and route lookup is always done with
hardware assist) and directing them and very simple processing that
only involves moving around a few header bit, such as generating
simple ICMP responses.

> I think one of the arguments against ICMP/LSP-PING is that it does not
> satisfy 3.7. It is not almost complete. It is lacking what many consider
> significant functional capabilities.
> 
> John


I think we should all discontinue this argument, agree to disagree,
and wait for the pudding.  Interoperability tests for MPLS related
things are generally held at GMU/AIL.  We'll see how many MPLS-OAM
implementations show up and interoperate.  We can also see how many
LSP-Ping and GTTP implementations show up and interoperate.  This
information can be fed back to the IETF since running code and
interoperable implementations still weigh in along with rough
consensus in the process.

Later,

Curtis