The MPLS WG Archive

[Loa Andersson <loa.andersson@utfors.se>]

All,

first of all I would like to thank all the vendors that tells me
what type of OAM I need! I can understand this, especially if their 
LSRs are out for 3-4 hours each months! It gives me a pretty good 
hint what I need to test in the future.

My problem is that if I had recurring outages like that - I would be 
out of business well before that first month ends - if I couldn't 
remove that equipment from my network before customers notice.

Normally I detect failures before customers.
Normally I've outages that is less than 1 minute a year.
The outages depends mainly on other reasons than that LSRs are
malfunctioning. Chain saws and earth moving equipment, mostly.
Can't see the OAM that takes care of that.

/Loa


Giles Heron wrote:
> 
> neil.2.harrison@bt.com wrote:
> [snip]
> > Do I therefore conclude that your company is happy to use customers as
> > defect detectors and 1st level fault management tools?  But maybe your
> > network has never, and will never, have failures (I wish I could say the
> > same for the ones I have knowledge of).
> 
> no - I do not use customers as defect detectors.  As I stated in another
> post I have dedicated management servers for this.
> 
> And as Dave McDysan pointed out MPLS OAM isn't sufficient for PW
> management, since errors can occur in the PW endpoints.
> 
> If your PW type has its own OAM (e.g. SDH/SONET, ATM) then I would
> suggest using that OAM function and treating the PW as one section of
> the path.
> 
> If your PW doesn't (e.g. Ethernet) then I would suggest injecting
> traffic onto measurement PWs.  Sure, this can't detect failures which
> only impact one specific PW endpoint, but then neither will MPLS OAM :(
> 
> Of course in an ideal world someone would invent an OAM for Ethernet.
> Anyone willing to volunteer?
> 
> > In any case, if one operator chooses not to employ pro-active
> > fault-management tools then that's OK providing they don't deny other
> > operators the ability to have them. (Did you see the list of carriers saying
> > they wanted the OAM work?....I hope you are not telling me they have all got
> > this requirement wrong?)
> 
> I hate to say this but...
> 
> > Further, if you have no well defined defect detection mechanisms, I'm
> > curious to know how you define/measure availability in a consistent manner
> > and how QoS metrics are started/stopped on availability state change (since
> > they are only valid in the available state).  Responsibility for the
> > standardised definition of these metrics (note **not** objectives) cannot be
> > abdicated by any stds body working in this area, since these metrics have to
> > be standardised so that operators/vendors can interwork (and interface with
> > OSS) in a consistent manner (and I am sure customers would like to see
> > standardised metrics so that they can compare services from operator X and
> > operator Y).  This latter requirement (ie metric standardisation) seems not
> > to have been understood I would say, and it is actually rather important.
> 
> don't worry Neil, there are others of us who are well aware of the fact
> that QoS measurements are only valid in the available state.  So yes, I
> do have a well defined defect detection mechanismm and it will measure
> availability and QoS :)
> 
> Giles
> 
> --
> =================================================================
> Giles Heron    Principal Network Architect    PacketExchange Ltd.
> ph: +44 7880 506185              "if you build it they will yawn"
> =================================================================

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           loa.andersson@utfors.se
WWW             www.utfors.se