Subject: RE: MPLS OAM? (was Re: PHP negotiation)

From: [email-masked]
Date: Mon, 19 Feb 2001 09:33:55 -0000

Mahadevan Iyer [mailto:[email-masked]] wrote 19 February 2001 05:23
> --- [email-masked] wrote:
> > or some joint metric (and which metric)?  Note:  OAM
> > is not usually about
> > accurate measurement of QoS metrics....OAM is more
> > about detecting failures
> > and taking appropriate consequent actions (eg
> > protecting customer data,
> > alerting Ops people).  Accurate QoS measurements
> > cost money to
> > measure/collect/process/analyse, and one 1st has to
> > define what are the 'up'
> > and 'down' states, since the QoS metrics/objectives
> > should really only apply
> > to the up-state (otheriwse they can quickly become
> > meaningless)
> 
> Neil,
> 
> From a service provider point of view, do they 1)use
> QoS measurements at all or are they 2)satisfied with
> detecting failures ?
NH=> This is not a simple question with a 'one solution fits all' answer.
It depends on the customer and the service.  And this can vary even for the
same type of 'service'....for example, I can imagine various VPN-types with
varying SLAs.  The technological solution (ie is it SDH-based, ATM-based,
FR-based, MPLS-based, IPSec-based) constrains the service and, even within a
given technology type, the nature of the SLAs can vary.  All I was trying to
point out in the initial response was that:
-	OAM will not do everything one wants performance-wise (you could
overload it, but my 80/20 experience suggest this is not a cost-effective
route)
-	OAM needs augmneting by detailed population sampling (to give
overall network figure of merit, which is usually not related to a given
customer, and to identify latent problems)
-	nodal/link utilisations (that feed into planning/forecast cycle and
TE activities)
-	and one may want to monitor UPC-like actions (ie
reclassification/discards) to check traffic profiles.
I am looking at OAM very much with an Operations perspective, ie I need to
be able to dectect/diagnose/handle failures 1st and foremost.....once I have
that sorted then I can worry about the other stuff afterwards.  
> 
> I guess this will tie into the billing/accounting for
> customers.
NH=> In some way yes. 
> 
> As a follow up question(if the answer to the previous
> question is 2) could one infer that billing/accounting
> is not actual usage/actual volume based. The customer
> gets charged for whatever was negotiated upfront. If
> there is a problem, the provider pays whatever is
> mentioned in the penalty clause.
NH=> This depends on the service and the customer.  The variables here are
too large to give a single answer.

---

From: [email-masked]
Date: Mon, 26 Feb 2001 09:33:57 -0000

Giles Heron [mailto:[email-masked]] noted 20 February 2001 15:27
<snipped>
> I'd say that you'd want to decouple defect handling from QoS
> measurement?
NH=> You must do this.  As I have said many time now, QoS is only valid when
the trail is in the 'up-state'.  So unless you know this 1st and foremost
(and this means having clear entry/exit criteria for unavailability which,
in turn, are predicated on clear entry/exit criteria for defects) then the
measurement of QoS has not robust foundation.
> 
> As far as I can tell the CV, BDI, and FDI flows are aimed at defect
> handling, and the P flow at performance/QoS measurement?
NH=>Effectively yes.....except that (i) the *degree* of QoS we want to
measure with the P flow needs agreeing (cost/benefit trade-off), and (ii)
availability is a QoS measure itself (indeed its the most important QoS
measure for customers).  So far in our debates on the P flow we have focused
on the next step-up (from defects) that we need to give Ops people for
in-service trouble-shooting....and this is somewhat different to 'pure' QoS
per se.  Recall....there are at least 4 activities that need some form of
QoS measurement (and one must overload one of these to do the task of the
others....again cost/benefit issue):
-	defects detection/diagnosis (aimed at Ops people, must measure
availability and protect customer traffic, eg security from
misrouting).....this is aspect we are concentrating on, since we see it as
the most important;
-	ad hoc detailed network QoS sampling (to give general trends and
spot latent problems)
-	node/link utilisations (feeds to TE and planning/forecast cycle)
-	policing/shaping actions (to watch for excessive
reclassification/discard activity)
> 
> It may be that this is an "either, or, or both" type of situation? 
> Defect handling could be applied to "trunk" LSPs in the 
> network (though
> in some ways I'd question the need for this in the presence 
> of the label
> distribution protocols - surely if a connectivity defect 
> occurs then the
> label mapping will be withdrawn by RSVP or LDP?) 
NH=> I think Peter Willis gave you some answers why this is not sufficient.
I could add more, but there seems little advantage to labour the clear
differences between user-plane and control-plane behaviour and why each
needs its own OAM tools.
><snip>
> 
> The CV, BDI and FDI flows should all be sent through the network with
> EXP values set for minimum loss/delay (I think you have specified this
> in your doc.)
NH=> We have considered these aspects quite carefully and hopefully got it
right.  Shahram has given excellent steer here.
<snipped>