Subject: OAM for MPLS networks

From: Calin Poenaru <[email-masked]>
Date: Tue, 27 Feb 2001 04:21:22 -0800 (PST)

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

---

---

From: [email-masked]
Date: Tue, 27 Feb 2001 17:18:07 -0000

Calin Poenaru [mailto:[email-masked]] observed 27 February 2001 12:21:
> a scheme which is very similar with I.610
NH=> The scheme in I.610 is flawed.  It can only detect simple breaks and
not generalised misconnectivity defects.   To do this requires an adjunct PM
flow.  Note that PM flow alone has a problem since the PM issue rate is a
function of customer activity, ie quiescent customer = zero PM flow = same
symptom as a break.  But CC+PM flow on all trails is far too heavy a
processing burden to scale.  So its not really the same at all. (Just taken
the best bits and discarded the bits that don't work or don't add-value)

> and (in my opinion) 
> has the same
> drawback - a time for detect and react too high.
NH=> CV detects all *MPLS layer* defects in same time of 3s.  Defect exit
time is also 3s.  Note that *below MPLS layer* defects (eg in SDH) would be
detected faster (consistent with the particular defect and its detection
mechanism within the SDH layer affected, eg loss of optics is detected as
LOS very quickly), and the FDI would be issued to the lowest layer LSP in
this (fast) time.

>  In other 
> words: the 10
> seconds necessary for detect
NH=> Defects are detected in 3s as noted above for MPLS layer defects, it is
not 10s.

> the unavailable state is far too long to
NH=> The definition of availability is independent of the defect detection
times as noted above.  We have used the classical 10s definition of WAN
availability for the following reasons:
-	there is no other as yet defined......so we had to choose something
-	below MPLS layer network technologies will be working to the 10s
value for availability.....so chossing something else would lead to
potential conflict of metric base.
BTW - it is not 20s to re-enter available state.  The process would work
like this:
-	assume in unavailable state with defect X
-	defect X is cleared (takes 3s)
-	traffic is re-enabled, ie after 3s
-	available state declared after 10s of defect-free state
-	last 10s get associated with up-state for QoS aggregation purposes.
Have another read, and if still not clear come back to me Calin.
> exit from this state and go into Near-End Defect State?
NH=> FDI pkts do *not* force defect state changes.  They are simply
indications that defects exist in lower layers and their key purpose is to
supress alarm storms.  Defects are *only* handled via the CV flow and
incoming FDIs get ignored....if this was not the case then there would be a
+3s extra 'hold-off' in the defect state at each LSP as one ascended a
stacked LSP hierarchy.  So, and your particular example,if one sees no BDI
pkts (and recall this is on a return LSP) *and* one sees 'good' CV pkts
then, irrespective of any rogue FDI pkts arriving (from wherever), its the
CV pkts that keep the return LSP in the up-state.  Hope its clear.

---

From: "David Allan" <[email-masked]>
Date: Wed, 28 Feb 2001 09:41:55 -0500

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:[email-masked]]
> Sent:	Tuesday, February 27, 2001 7:21 AM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	OAM for MPLS networks
> 
> 
> Hello!
>