The MPLS WG Archive

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

Title: RE: OAM for MPLS networks

Calin:

I think you need to rephrase the questions along the lines of "what failure detection tools do I have" and optimize the hell out of the one that involves the least amount of state and overhead and "garbage collect" with the rest at a much lower level of activity. For many of us, this means fate sharing with the control adjacency whereby a single state machine proxies for all the LSPs on a link, which should quickly catch the majority or gross failures (errant backhoes, melting lasers and the like).

The issue is that the control adjacency as a proxy does not catch subtle "per LSP" defects which are much harder to track down. So from that perspective, a mechanism is required to detect such failures, but as we are looking at a less frequent case, I would hope we can live with longer detection time and balance this with the amount of resources we need to commit to per LSP OAM. My read of this draft suggest that the proposed OAM is designed to deal with this type of failure and the 10 second number should not be projected onto detection of all types of failure. In fact we probably could go longer.....

cheers
Dave

-----Original Message-----
From:   Calin Poenaru [SMTP:calin@employees.org]
Sent:   Tuesday, February 27, 2001 7:21 AM
To:     mpls@UU.NET
Cc:     neil.2.harrison@bt.com
Subject:        OAM for MPLS networks




Hello!

I have a question about the efficiency of the mechanism for connectivity
verification described in draft-harrison-mpls-oam-00: there is proposed
a scheme which is very similar with I.610 and (in my opinion) has the same
drawback - a time for detect and react too high.  In other words: the 10
seconds necessary for detect the unavailable state is far too long to
affect all the connections in the failed LSP. And more, the 20 seconds
(minimum) required for re-entering in the available state is too much to
be useful for the traffic (in this time the Control Plane probably already
take some actions like reroute or something else). Could you comment a
little bit about this issues?

And another question: at 6.6.3 you stated that the exit from Far-End
Defect State is conditioned by 3 consecutive seconds without BDI OAM
packets. But what if an FDI OAM packet will come? It will not force the
exit from this state and go into Near-End Defect State?

Thank you in advance for your time!

Best regads,

Calin

---