Subject: RE: PW Availability

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 5 Apr 2004 13:42:44 -0400

Hi Neil,

Continuing on the discussion about the definition of availability.
 
NH> "there is need to aim for harmonisation of NP/availability metrics and objectives across all layer networks"

I don't understand what we are harmonizing. It seems that all existing protocols use different ways of fault detection and performance measurements and Y.1711 introduces yet another way of doing things. Particular anomalies will be detected in one technology and not in another. E.g., if I am not mistaken, a four-second break would be detected in Y.1711 as a defect and would lead to a suspension of performance measurements, while the same break would not be registered as a defect in ATM. This is just one example. In earlier emails, you have pointed out other differences between the various technologies.

Therefore, in today's world, an operator can not easily compare network performance data obtained in one technology with performance data obtained in another.

Furthermore, networks are becoming increasingly divers. With IP VPN or VPLS services, nodes that do connectionless forwarding (i.e. the PEs) can be interconnected through large connection-oriented islands. A single IP VPN instances may have traffic passing through both ATM and Ethernet access networks and an MPLS core network.

It seems to me that the only way Service Providers can deal with such a situation is by using sophisticated performance monitoring tools that gather information from the various independent network layers and islands and do the harmonization and sanitization off-line. 

In other words, the notion that we can create an OAM model in MPLS and turn that into a consistent end-to-end mechanism by proper layering, FDI, etc, does not seem to jibe with (1) the existence of legacy networks; and (2) the nature of tomorrow's services.
 
Another wrinkle: BFD allows the operator to decide how often control messages are sent. The detection time of a defect is a multiple of the specified period. Therefore, if an operator decides to use an interval in the order of minutes, it does not make much sense to define availability with a granularity of seconds.

I would conclude that it does not make much sense to define availability as part of a network layer OAM spec. If you have a clear definition of defects - depending on the tools that are used for failure detection - it should be up to an off-line performance monitoring tool to translate information on defects and performance measurements to harmonized indicators that are useful to the operator.

Peter

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 30, 2004 5:46 AM
> To: [email-masked]; [email-masked]
> Subject: RE: PW Availability
> 
> 
> Thanks Peter.....I have some responses for you 
> in-line....sorry for the delay.  regards, Neil
> 
> > -----Original Message-----
> > From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> > Sent: 25 March 2004 20:49
> > To: Harrison,N,Neil,IKR2 R; [email-masked]
> > Subject: RE: PW Availability
> > 
> > 
> > Neil,
> > 
> > I would be happy to add to 
> > draft-nadeau-pwe3-oam-msg-map-04.txt that a PW is declared 
> > unavailable if a defect persists for more than 10 seconds. 
> > However, at this point I am not sure what that means since I 
> > don't know how it affects anything that goes on in the network.
> NH=> OK.  But please note:  
> -	you will have seen my explanation of the origins of the 
> definition of availability and how I think it should be 
> simplified, re how Y.1711 has addressed this.
> -	there is need to aim for harmonisation of 
> NP/availability metrics and objectives across all layer 
> networks.......this becomes even more obvious as a 
> requirement if there is no control over client/server layer 
> relationships (though as I have noted before some C/S 
> relationships between the 3 modes make far more sense than others)
> -	both availability and NP aspects can be sensibly 
> associated with trails.  Only co-cs and co-ps modes have 
> trails.  So for MPLS these metrics need to be associated with 
> an LSP.  Sure you can try and associate them with a PW but we 
> don't network PWs, ie we do not switch, nest as 
> client/server, etc PWs since they are an adaptation function. 
>  I know most folks seem to struggle to grasp this but it 
> is/will be a real limiting problem for MPLS....that is, a PW 
> lives in no-mans land between a given client (eg FR, ATM etc) 
> and either a cl-ps IP server layer or a co-ps MPLS server 
> layer.  I am really puzzled however why folks find this hard 
> to understand technically?
> > 
> > You have mentioned that it is important to recognize such a 
> > state, because it determines when Performance Monitoring 
> > should be started and stopped. However, from your response to 
> > my last email, it appears that a clear and realistic approach 
> > to Performance Monitoring does not exist yet. Therefore, I 
> > wonder what the point is of introducing concepts that may or 
> > may not be relevant in the future.
> NH=> This is not a logical argument.  If you don't get the 
> ordering right then yes for sure you have a self-fulfilling 
> prophecy that that there is no chance to get the NP aspects 
> sorted.  However, if you do get the ordering right then when 
> you are ready to measure NP you have the right basis.  NP is 
> 2nd order in importance to defect detection/handling.  We 
> have not discussed NP issues yet. You can also easily end up 
> specifying way too many complex/unnecessary NP stuff that, in 
> terms of its real benefit in a network, is an illusion of 
> efficiency.  The 'QoS challenges' are not about having loads 
> of classes in 1 mode, but they are all about how to deliver a 
> suite of public/private services that are consistently 
> meaningful across a large range of network load points, and 
> thus allow SPs the ability to charge a fair price for doing 
> so.  Real networks run lightly loaded for most of their 
> working life (for lots of reasons).  Having lots of QoS 
> classes won't help you with this goal if:
> -	you can't differentiate 'urgency' and 
> 'importance'......and this is one reason why there is a big 
> difference between having the co-ps mode trail (eg LSP) or 
> only the cl-ps mode pkt (eg IP) as the networked entity;
> -	resource sharing is allowed between traffic 
> classes....since this kills any sensible notion of 'QoS 
> differentiation' dead.
> > 
> > Therefore, I propose that we add the following statements to 
> > draft-nadeau-pwe3-oam-msg-map-04.txt:
> > 
> > a) in general (i.e. for other technologies), operators 
> > consider a connection unavailable of a defect persists for 
> > more than 10 seconds
> > 
> > b) the interaction between PW fault management and 
> > Performance Monitoring is for further study.
> NH=> OK, seems this group is hell-bent of defining all the 
> networking stuff round PWs rather than the LSP and pkt 
> networked entities of the co-ps and cl-ps modes respectively. 
>  Its wrong of course, but I alone can't stop you.  Some 
> further remarks below.  
> > 
> > Further comments in-line.
> > 
> > Peter
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, March 24, 2004 5:53 PM
> > > To: [email-masked]; [email-masked]
> > > Subject: RE: PW Availability
> > > 
> > > 
> > > Peter..
> > > > 
> > > > Neil,
> > > > 
> > > > A while ago we exchanged emails on the availability of Pseudo 
> > > > Wires. The relevant part is attached to this email.
> > > > 
> > > > I agree with the observations you made, but my main question 
> > > > was not answered: if you emulate a service over PWs,
> > > NH=> Can you define precisely what 'emulate' means here?
> > > 
> > 
> > I meant "emulate" in the same way as it is used in all WG 
> > drafts and emails on this mailing list: the encapsulation of 
> > client traffic so as to transport it over a PSN.
> NH=> Oh yes I know, that is why I asked you to flush this 
> point out.  Its imprecise, and is thus a meaningless 
> statement.  This is not a good starting point for operators 
> who regard MPLS as a key core target technology.  I think its 
> high time folks stopped pretending MPLS is the same as 
> IP....its wrecking the potential of MPLS IMO.  XoverMPLS is 
> not the same thing as XoverIP.  We can manage trails in a 
> co-ps mode like MPLS, we cannot do that in a cl-ps mode like 
> IP.  That is simply a fact which, for whatever reason, some 
> folks here seem unable (or more likely 'unwilling') to 
> comprehend/accept.  Speaking as an engineer who has been 
> brought-up to believe in honesty and accuracy, I find this 
> 'sticking one's head in the sand' behaviour of ignoring the 
> truth rather disturbing. {Note - this is not the same as 
> saying I won't accept compromises....I have no problem with 
> that *providing* they are recognised as such (eg arch 
> violations) and we understand the implications of them.  I 
> only have problems when folks tell me they are 'right' and 
> won't even recognise identified problems.}  
> > 
> > > > is it 
> > > > really necessary to measure Network Performance (NP) of the 
> > > > PW itself?
> > > NH=> Pass.  Depends on what the definition of 'emulation' 
> > > really meens (and I have no idea) and what a PW actually 
> > > is....to me its some form of adaptation.  XoverIP could have 
> > > different perf to XoverMPLS....the defect behaviour is for 
> > > sure very different.  I think folks really ought to 
> > > differentiate these 2 cases as they are obviously not the same.
> > 
> > I may be naive, but I would think that Network Performance to 
> > the extend that it relates to SLAs should be independent of 
> > the network layers over which the service is carried.
> NH=> The whole point of my repeated observations about the 3 
> networking modes and client/server inheritance is to show 
> this is not true.  The behaviour of a cl-ps mode network is 
> different to a that of a co-ps mode network is different to 
> that of a co-cs mode network.  One introduces constraints to 
> the basic 'broadcast at source, filter at sink' mode (that 
> ethernet uses) to get these 3 wide-area modes.....and one 
> does this because they bring benefits in 
> scaling/design/operation/NP/mtce/etc....in other words the 
> network becomes simpler as we move towards the co-cs mode.  
> If not obvious, consider the fact that the co-cs mode has 
> *no* traffic/QoS classes at all.....and just think how much 
> simpler 
> routing/signalling/resource-accounting/fault-management/etc 
> is therefore.  So if a co-cs mode is the server layer then 
> the client layer cannot get any better *inherited* NP than 
> this.....remember, each layer network will inherit the NP of 
> its server layer and this is recursive to the duct.  There 
> are 9 combinations of client/server relationships between the 
> 3 modes.....some make more sense than others.  We cannot be 
> prescriptive about this (and currently there are no stds that 
> describe this or control how many times one is allowed to go 
> up/down a network stack of different modes)....however we can 
> use common sense ;-)
> > 
> > In fact, you assertion that defect behavior of IP and MPLS 
> > networks is so different that XoverIP and XoverMPLS should be 
> > considered as two totally different solutions suggests that 
> > NP measurements of X would yield completely different results 
> > in the two cases. I can't see why that would be desirable to 
> > Service Providers.
> NH=> Can't you?  Blimey that is of concern then.  As a hint 
> go check real core network utilisations, esp when one has 
> uncertainty of behaviour under failure.  But let me try and 
> help further:  In a cl-ps network you only have one traffic 
> entity.....the pkt.  In a co-ps network you have 2 traffic 
> entities.....the parent trail and the child pkt.  The trail 
> is the dominant entity here.  One can therefore provide 
> additional constraints to the co-ps mode that don't exist in 
> the cl-ps mode, eg you can explicitly control the directivity 
> by signalling, and the survivability of the parent trail 
> entity can be completely decoupled from the (child pkt) 
> traffic it carries.....a rather important feature IMO, esp 
> for VPNs (noting that this can be generalised to include all 
> client/server cases since these are, if you think about it, a 
> form of 'VPN').  Now if you really wanted to see the power 
> the co-ps mode can unlock for you I would need to get into a 
> discussion of what QoS/NP really means....but that is another 
> long story however.
> 
> But hang on a minute......this should all be obvious to 
> network engineers.  This is starting to feel like I am giving 
> some lecture on networking basics.
> >  
> > > 
> > > > If a Service Provider measures NP on end-to-end 
> > > > ATM VCs, why is it necessary to obtain additional NP 
> > > > measurements on one specific segment?
> > > NH=> To see where impairments are coming from say.  In a more 
> > > general case if you have some global reference connection 
> > > with metrics A, B, C that have objectives a, b, c (to be met 
> > > over some period, eg month), you need some way to fairly 
> > > apportion these to  partitions of the end-end path, eg to 
> > > countries or operator domains.  So each partition need to 
> > > check its bit is within its apportioned target.
> > > > 
> > > > Now, assuming that a Service Provider wants to measure NP of 
> > > > PWs, how does that work?
> > > NH=> I have no idea....you are starting down the very 
> > > slippery slope of making a PW a networked entity....and it is 
> > > not (as yet anyway).
> > 
> > I am  not sure who started down the slippery slope.
> NH=> I'll tell you then.  It was those folks who wanted to 
> 'do' stuff like FR and ATM without deploying native 
> technologies.  Quite understandable.  However, its one thing 
> doing a cheap/cheerful expedient technology emulation (over 
> either IP or MPLS), but its quite another thing to then say 
> PWs are the basis of next gen networks for everybody.  AFAI 
> can tell, the direction here is network convergence on 
> PWs.......but I think most operators want a convergence on 
> MPLS.  But PWs are not even a layer network, and the real 
> layer networks of IP and MPLS are not the same.....if there 
> were the same then why did MPLS come into being in the first 
> place?  Every time I make this observation folks ignore 
> it....I assume because its something some would rather was 
> not recognised (though these same folks don't seem to have a 
> problem recognising that SDH and OTNs are co-cs mode networks 
> when talking about GMPLS....there are some very strange 
> double-stds being applied here IMO).  This attitude is not 
> healthy IMO.  Its not allowing the full potential of MPLS to 
> be seen/developed, and IMO its also an attempt to hide (or 
> maybe justify) some arch violations of MPLS IMO.  Now I know 
> there are religious/commercial factors at play here, but I am 
> trying to be brutally honest about 'networking truths'.....I 
> used to think that 'technical honesty/accuracy' was something 
> that was held in high esteem in IETF, but I have had to 
> change my views on that.
> 
> 
> > I did not 
> > say there was a need for an availability state for PWs. You 
> > did.
> NH=> Yes, but it is now a logical conclusion of what has been 
> done here.  A PW is now a unifying adaptation function above 
> either an IP server layer network or an MPLS server layer 
> network.....but it does not exist in its own right as a layer 
> network interface.....you still have FR, ATM, or whatever 
> above this.  We do not (as yet anyway) 'network' PWs but we 
> do network IP pkts and MPLS trails.....and pkts and trails 
> are quite different network entities.  However, given the 
> status of this discussion I fear you either honestly don't 
> get this (which I find hard to believe in your case) or you 
> are unwilling to recognise it for some other reason.
> 
> >I am actually arguing for the position that it doesn't 
> > make sense to measure NP for Pseudo Wires.
> NH=> Good, that is something we agree on then.  I am actually 
> arguing for an acceptance by the community that there are 3 
> networks modes.  SDH and OTNs belong to the co-cs mode.  IP 
> and ethernet belongs to the cl-ps mode (though only IP has 
> proper addressing/routing).  MPLS, ATM and FR belong to the 
> co-ps mode.  These modes have fundamentally different 
> behaviours....that is why they were created in the first 
> place for goodness sake.  These are simply 
> facts....pretending they are not true is not helping anyone 
> in the long-term.  Now given your statement above, I 
> therefore have to assume that you also agree that the NP 
> needs to be associated with the real network then....so that 
> is either IP or MPLS.  I want to associate *all* the 
> networked attributes (ie defects, availability, NP) with the 
> LSP in MPLS as its this that is the networked entity.  One 
> manages trails in a co-ps mode network quite differently to 
> how one manages pkts in a cl-ps mode network.   
> > 
> > > 
> > > > I assume that it is based on 
> > > > comparing packet counts both at ingress and egress. Following 
> > > > the method proposed by Y.1711, performance measurements are 
> > > > stopped upon detection of a defect and restarted a certain 
> > > > period after the defects disappears and the connection is 
> > > > stable again. However, in general a defect exists some time 
> > > > before a connection end-point finds out. Therefore, a number 
> > > > of packets will have been dropped already. Rather than trying 
> > > > to minimize the effect of this time lag by specifying 
> > > > available/unavailable state, as Y.1711 does, would it not 
> > > > make more sense to sanitize the data in an off-line 
> > > > performance monitoring tool that can exclude counts taken 
> > > > just before the defect occurred?
> > > NH=> Y.1711 has not defined any NP collection yet.  Its more 
> > > important to get the basic defects, short-breaks and 
> > > unavailability bits done 1st.  NP stuff can be added later on 
> > > this firm defect detection/handling basis.  I can think of 
> > > some smart/simple ways of doing NP collection however.....the 
> > > details are not given in Y.1711 right now. One also has to be 
> > > aware of 'PDUs in flight'.  
> > > > 
> > > > In short: how exactly do Service Prodivers measure Network 
> > > > Performance?
> > > NH=> Badly to date is my view.  Why?  Because the ordering I 
> > > mentioned in the mail below has never properly been executed 
> > > in the past.
> > 
> > I am not sure what point you are trying to make. Service 
> > Providers (BT being one of them) have large networks in which 
> > they run ATM over SDH or SONET. I was not asking a rhetorical 
> > question. I am genuinely interested to learn more about 
> > operator experiences.
> NH=> And the answer I gave is correct.  We really do not do a 
> good job, because whilst I.610 may look superficially OK, 
> there are several problems with it....and they started 
> because folks initially focussed on NP/QoS and forgot about 
> the more basic defect detection/handling first.  I can 
> explain but its yet another long story.
> > 
> > However, if you say that even ATM-over-SDH
> > is such a mess 
> NH=> No, SDH is fine.  Its ATM's OAM that is not good in some 
> respects.  The problem with ATM was that folks got far too 
> interested with NP metrics and defining lots of traffic 
> classes (we had 5 AALs at one stage).....a complexity that we 
> can now see was largely unnecessary....and they forgot about 
> attending to the less sexy basic stuff, like defining defects 
> and their detection/handling.  So ATM's OAM is far from 
> ideal.  I can explain why if you are really interested.
> 
> > that decent Performance Monitoring is not possible, then what 
> > does that mean for our current work?
> NH=> Which current work?  Y.1711 is fine.  It corrects the 
> problems in I.610.
> 
> > Existing networks will 
> > not go away for a long time to come.
> NH=> Agreed.  That is why if we continue to screw things up 
> by not facing up to network arch truths early its us 
> operators who will be left paying for it for many years 
> hence.  This is why I will not let folks off the hook who 
> continue to violate func arch rules just because it might 
> suit them right now in selling boxes.
> 
> > We have to work with 
> > what we have. Especially with regards to PWE, I don't see how 
> > we can work on Performance Monitoring without taking existing 
> > protocols and techniques into account.
> NH=> I would understand if you you were talking about going 
> back and trying to redo FR and ATM say. But one should not be 
> specifying stuff in stds that are still draft and known to be 
> flawed.  We and other operators have not yet built our next 
> generation networks, ie a converged core on MPLS.  PWs are 
> not a common deployed legacy technology.  MPLS is only used 
> today in niche applications.  We are very concerned about the 
> arch flaws in some types of MPLS and its missing functional 
> components.  Similarly, we are also concerned about PWs that 
> are then based on these.  We therefore do not regard these 
> technologies as legacy in the same way as FR or ATM.  MPLS is 
> currently not fit for purpose as a future key convergence 
> technology.  You appear to be insisting here that because 
> someone has made some errors in the past with some types of 
> MPLS that these must be visited on all future work and 
> imposed on all operators....why?  We have the chance to 
> correct these.  Why is it not possible to get the stds right 
> now based on respecting the func arch requirements?
> 
> regards Neil 
> 
>

---

From: [email-masked]
Date: Mon, 5 Apr 2004 22:01:34 +0100

Hi Peter.....please see below.  

> Sent: 05 April 2004 18:43
> NH> "there is need to aim for harmonisation of 
> NP/availability metrics and objectives across all layer networks"
> 
> I don't understand what we are harmonizing.
NH=> Yes, I can understand why it is confusing....esp given there are (i) no rules to control which layer network can be a client or server to some other layer network and (ii) how many such transitions could be allowed in a given instance of some overall HRX across many operator partitions for some application.  Though I can actually see this argument as being in favour of more harmonisation rather than against it.

> It seems that all 
> existing protocols use different ways of fault detection and 
> performance measurements and Y.1711 introduces yet another 
> way of doing things.
NH=> This was certainly not the intention.  I agree we have had the situation where each new technology that has emerged has done its own thing wrt its functional components....these are things like addressing, routing (required for all scalable modes) signalling  (for the co-ps/co-cs  modes), OAM, etc.  But if one agrees that:
-	all technologies map to one of these modes
-	we don't need lots of technologies belonging to the same mode.....since they are all essentially doing the same job
-	but we do actually need the 3 modes since they are doing different jobs (and as we move from cl-ps to co-ps to co-cs the increasing constraints applied result in important design/operational simplifications and benefits)
.......then there ought to be a 'best-of-breed' way of doing things for each mode.

When I was looking at the best-of-breed defect detection/handling solution for the co-ps mode the above thinking was central.  In fact, I can recall a conversation between myself and Maarten Vissers from a long time ago where we agreed that to stop this re-invention of functional components (in our case OAM) we ought to try and get it right next time....we were, at the time, reflecting on the problems we had uncovered in I.610 OAM for ATM because folks had not focussed on the basics, but instead rushed off into the network performance/QoS stuff.  So Y.1710/11 is not just 'something different' yet again for the sake of it, the intention was to try and get the basic defect detection/handling right at the outset for any technology belonging to the co-ps mode.

And if you think about many of the arguments I put forward for using functional arch techniques and avoiding arch violations, it is again based on trying to do thing right from the outset.

> Particular anomalies will be detected in 
> one technology and not in another. E.g., if I am not 
> mistaken, a four-second break would be detected in Y.1711 as 
> a defect and would lead to a suspension of performance 
> measurements, while the same break would not be registered as 
> a defect in ATM. This is just one example. In earlier emails, 
> you have pointed out other differences between the various 
> technologies.
NH=> We cannot go back and re-spin ATM now.  All I can argue for is trying to so things right in the future based on lessons learnt.
> 
> Therefore, in today's world, an operator can not easily 
> compare network performance data obtained in one technology 
> with performance data obtained in another.
NH=> I do agree (esp across technologies belonging to different modes), but this is no argument for keep making mistakes is it....or even making things worse?  For example, the problems of ATM OAM I have alluded to are small beer compare to the OAM problems that are created by violating the architecture of the co-ps mode.  I sincerely hope you are not trying to tell me that mp2p constructions in the co-ps mode and the resultant LSP-Ping is an advancement in network OAM for operators are you?  
> 
> Furthermore, networks are becoming increasingly divers. With 
> IP VPN or VPLS services, nodes that do connectionless 
> forwarding (i.e. the PEs) can be interconnected through large 
> connection-oriented islands. A single IP VPN instances may 
> have traffic passing through both ATM and Ethernet access 
> networks and an MPLS core network.
NH=> Yes, the increasing complexity issue is a real concern.  This is also why it is increasingly important to properly understand what is happening in functional architecture terms.  When client/server layer relationship are done right folks don't even notice them, eg when one sees a 'cloud' diagram don't forget that between each of the nodes in the client technology considered are (transparent) server layer trails.  This is so often taken for granted.  This is why I am not at all impressed with folks who think compressing a client layer network is a 'good thing'....its isn't, its actually a 'bad thing'.
> 
> It seems to me that the only way Service Providers can deal 
> with such a situation is by using sophisticated performance 
> monitoring tools that gather information from the various 
> independent network layers and islands and do the 
> harmonization and sanitization off-line.
NH=> The complexity we are seeing unfold today is not sustainable in the long-term IMO......esp if the ability to deliver truly differentiable/meaningful/consistent network services (both private and public) over a range of load points is not possible.  There are smarter ways to do things IMO.  However, I suspect we may have to learn these the hard way.
> 
> In other words, the notion that we can create an OAM model in 
> MPLS and turn that into a consistent end-to-end mechanism by 
> proper layering, FDI, etc, does not seem to jibe with (1) the 
> existence of legacy networks; and (2) the nature of 
> tomorrow's services.
NH=> It for sure won't happen if you do not plan for it.  And it also depends on how one views the role of MPLS.
>  
> Another wrinkle: BFD allows the operator to decide how often 
> control messages are sent. The detection time of a defect is 
> a multiple of the specified period. Therefore, if an operator 
> decides to use an interval in the order of minutes, it does 
> not make much sense to define availability with a granularity 
> of seconds.
NH=> I understand.  So one consciously decides not to have consistent defects, etc.  That is workable within a single domain, but it means there are problems when one wants to i/w with other operators.  What is the basis now?  Is it bilaterally negotiated with no client layer alarm suppression?  What happens when a customer complains....how do we identify the whose partition is breaking their apportionment (and how is this apportionment decided?) of some end objective (and what are these now)?  Takes me back maybe 20 years if that is the case.
> 
> I would conclude that it does not make much sense to define 
> availability as part of a network layer OAM spec. If you have 
> a clear definition of defects - depending on the tools that 
> are used for failure detection - it should be up to an 
> off-line performance monitoring tool to translate information 
> on defects and performance measurements to harmonized 
> indicators that are useful to the operator.
NH=> I can see what you are saying.  Though as noted above when it comes to defining global i/w cases then a lack of agreed metrics would seem to be a problem.  I would however assume, as a minimum, consistent/automated defect detection/handling would be something most operators would still like to see.

General comment - I am arguing for more simplicity and consistency based on past experience of not having this.  I think you are arguing for more choice and diversity also based on past experience of not having this.  Well, all I know is that our Ops folks have never been that happy in the past with OAM (except perhaps with SDH) and they are for sure not impressed with what they are getting today.  But then if the Operator community does not collectively argue/agree for what it wants then they deserve no better than what they get.

regards, Neil