The MPLS WG Archive

[Dave McDysan <dave.mcdysan@wcom.com>]

I believe that IPPM is based upon a probe technique, similar to what Neil
had described in his post, which is why I had mentioned it. Just trying to
communicate to avoid duplicate efforts to deliver similar function.

Dave

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram
> Davari
> Sent: Thursday, December 13, 2001 5:03 PM
> To: 'Dave McDysan'; 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
>
>
> 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
> >
>