The MPLS WG Archive

[neil.2.harrison@bt.com]

Brian/Kireeti,

Please see my observations below.  regards, Neil

Brian Hassink wrote 21 October 2002 22:09
<snip>
> >[BH] Also, couldn't a (optional) "timestamp" TLV be defined rather than
> > having this information as mandatory fields in the main header?
> 
> [KK]Any particular reason?  One could make TLVs of all fields, 
> not just the
> timestamp fields.
> 
> [BH] I think that measuring delay/RTT is not necessarily 
> something you want to combine with testing/validating 
> connectivity. And again, if this "protocol" evolves to 
> support other inband OAM functions, then it may become even 
> less relevant to a given function. 
NH=> I agree.  It's a sensible idea to decouple performance metric
measurements from defect detection/handling.....where the latter essentially
boils down to some *standardised* test of connectivity.  The reason why the
defect/connectivity testing needs to be 'standardised' is so that we can
compare apples with apples.....obviously important when running services
across multiple operator networks.  Similarly, it is also important to
standardise the definition of the performance metrics too, and also their
end-end and partitioned objective allowances so that operator's can set fair
allocations.  However, the specification of performance metrics and their
objective allocations can't be really addressed until the basic defect
detection/handling mechanisms are sorted.

There are further practical reasons for decoupling performance metrics from
defect detection/handling:

-	the one Brian has pointed out, ie it's not usual to to measure
performance metrics as a continuous-time function (80/20 rule).  The ability
to have on-demand performance metric measurements is useful for situations
like:
	* ad hoc trouble-shooting/diagnostics at a finer level than the
basic defect detection/handling;
	* on important paths where it is deemed important to have such
measurements running continuously;
	* sampling of network paths (according to some population selection
method) in order to get a feel for the general performance (of some metric x
say) of the network.

-	to make the definition of defect entry/exit criteria as simple as
possible.  If we do not do this then we can end up with complex
combinatorial problems of defining 'up' and 'down' states of a path/network,
ie as some aggregate function of varying levels of degradation across a set
performance metrics x, y, z say.