The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Dave,

One of the basic principles we had in mind was decoupling of QoS and user behavior from availability measurement. IPPM works if we have traffic from customer all the time. When customer is not sending traffic it looks like the LSP is down. Also during congestion, QoS could be bad but be perceived as loss of connectivity.

-Shahram

> -----Original Message-----
> From: Dave McDysan [mailto:dave.mcdysan@wcom.com]
> Sent: Thursday, December 13, 2001 1:33 PM
> To: neil.2.harrison@bt.com; dcooper@gblx.net; 
> dallan@nortelnetworks.com
> Cc: tnadeau@cisco.com; mgibson@orchestream.com; mpls@UU.NET
> Subject: RE: MPLSOAM BOF meeting draft minutes
> 
> 
> 
> 
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > neil.2.harrison@bt.com
> > Sent: Wednesday, December 12, 2001 7:22 PM
> > To: dcooper@gblx.net; dallan@nortelnetworks.com
> > Cc: tnadeau@cisco.com; mgibson@orchestream.com; mpls@UU.NET
> > Subject: RE: MPLSOAM BOF meeting draft minutes
> >
> >
> > Hi Dave (C),
> >
> > I think they can co-exist.  Operators need tools that can 
> detect defects
> > automatically (ie no waiting for the complaint to roll-in) and take
> > immediate distributed executive actions as needed.  We also 
> need these to
> > get some consistency amongst vendors for defect definitions 
> (entry/exit
> > criteria) and ideally an availability metric (this does not 
> imply the
> > *objectives* that such metrics have to meet, but the metrics
> > themselves must
> > be consistent across all parties).  To me these are 1st line
> > must-have fault
> > management tools.
> 
> Agree that these are the essence of some important 
> requirements. Have you
> looked at the IPPM definition and means to measure 
> "connectivity," which can
> be interpreted as a measure of "availability."
> 
> Regards,
> 
> Dave
>